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ABSTRACT 


The  purpose  of  this  research  was  to  introduce  a  Transformational 
Communications  Architecture  for  the  Unit  Operations  Center  (UOC);  Common  Aviation 
Command  and  Control  System  (CAC2S);  and  Command  and  Control  On-the-Move 
Network,  Digital  Over-the-Horizon  Relay  (CoNDOR). 

The  methodology  used  was  to  conduct  Field  Tests  with  government  contractors 
and  private  vendors  in  order  to  demonstrate  the  capabilities  of  each  wireless  technology 
researched.  These  wireless  technologies,  Free  Space  Optics  (FSO),  Microwave,  802.16, 
802.11b  over  SecNet-11,  Orthogonal  Frequency  Division  Multiplexing  (OFDM), 
Broadband  Satellite,  INMARSAT,  and  Iridium,  all  have  the  potential  of  being 
implemented  in  the  transformational  communications  architecture  for  intra-nodal  and 
inter-nodal  links  for  UOC  and  CAC2S,  as  well  as  the  CoNDOR  communications 
architecture.  The  ultimate  goal  of  this  research  was  to  introduce  different  technologies 
that  offer  more  flexibility,  mobility,  and  capability  at  the  tactical  level  giving  the  Marine 
Corps  the  tactical  wireless  edge. 

Throughout  this  research,  the  focus  revolved  around  testing  equipment  and 
network  configurations  in  an  IP  network.  Special  consideration  was  given  to  wireless 
issues  for  the  UOC,  CAC2S,  and  CoNDOR,  which  could  improve  line-of-sight,  beyond 
line-of-sight,  and  over-the-horizon  communications  for  each  program.  These  new 
technologies  will  transform  communications  in  the  United  States  Marine  Corps  for  the 
21®'  century. 
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THESIS  ROADMAP 


For  readers  who  need  a  quiek  explanation  of  this  thesis  research,  read  the 
executive  summary,  conclusions,  and  recommendations.  The  reader  will  find  the  thesis 
in  the  following  order:  table  of  contents,  list  of  figures,  list  of  tables,  acknowledgements, 
executive  summary,  Chapter  I  (Introduction),  Chapter  II  (Field  Tests),  Chapter  III 
(Findings  and  Analysis),  Chapter  IV  (Conclusions),  Chapter  V  (Recommendations), 
Appendix,  list  of  acronyms,  and  initial  distribution  list. 

Chapter  I  discusses  the  problem  and  background  information  on  UOC,  CAC2S, 
and  CoNDOR.  The  problem  addresses  the  fundamental  reason  for  conducting  this  thesis 
research,  and  the  background  information  gives  a  summary  of  the  different  programs  that 
are  being  studied. 

Chapter  II  explains  in  detail  how  each  field  test  was  conducted.  This  chapter  only 
discusses  the  procedures  of  each  field  test.  For  results  of  each  test,  the  reader  must  read 
Chapter  III  (Findings  and  Analysis).  Chapter  III  summarizes  the  results  of  the  four  field 
tests  and  gives  detailed  findings  and  analysis. 

Chapter  IV  discusses  the  conclusions  for  the  UOC,  CAC2S,  and  CoNDOR 
programs.  In  this  chapter,  the  technologies  examined  are  associated  with  the  potential 
use  in  each  program. 

Chapter  V  provides  recommendations  for  the  UOC,  CAC2S,  and  CoNDOR 
programs.  The  reader  can  learn  what  can  be  implemented  now  in  each  program.  In 
addition,  the  reader  can  find  out  what  could  be  implemented  in  the  future  for  each 
program,  how  this  research  ties  into  a  FORCEnet  application,  and  what  can  be  done  as 
follow-on  research. 

The  Appendix  contains  a  summary  of  each  product  used  in  this  thesis  research 
and  supplemental  information  that  further  assists  the  reader  while  reading  the  paper. 

Finally,  the  thesis  ends  with  a  list  of  acronyms  and  an  initial  distribution  list. 
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EXECUTIVE  SUMMARY 


The  purpose  of  this  research  was  to  introduce  a  Transformational 
Communications  Architecture  for  the  Unit  Operations  Center  (UOC);  Common  Aviation 
Command  and  Control  System  (CAC2S);  and  Command  and  Control  On-the-Move 
Network,  Digital  Over-the-Horizon  Relay  (CoNDOR). 
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trip,  they  formulated  a  plan  to  do  ‘backyard’  testing  of  several  commercial  off-the-shelf 
technologies  in  the  Monterey,  CA  area.  Two  months  later  after  some  intensive 
coordination,  they  went  to  General  Dynamics  in  Scottsdale,  AZ  and  Raytheon  in  San 
Diego,  CA  to  conduct  testing  with  the  UOC  and  CAC2S  program  offices  respectively. 
Finally,  they  completed  their  testing  evolutions  with  a  realistic  tactical  scenario  that 
resembled  the  CoNDOR  architecture  at  Camp  Roberts,  CA  in  March  2004. 

In  November  2003,  Captain  Joseforsky  and  Captain  Garcia  orchestrated  a  team 
(LT  Jesus  “Manny”  Cordero  and  LT  A1  Seeman)  in  order  to  achieve  individual  thesis 
work  for  NPS.  Overall,  over  25  U.S.  Government  agencies,  government  contractors,  and 
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accomplish  their  thesis  objectives. 

The  wireless  technologies  that  were  researched.  Free  Space  Optics  (FSO), 
Microwave,  802.16,  802.11b  over  SecNet-11,  Orthogonal  Frequency  Division 
Multiplexing  (OFDM),  Broadband  Satellite,  INMARSAT,  and  Iridium,  all  have  the 
potential  of  being  implemented  in  the  transformational  communications  architecture  for 
intra-nodal  and  inter-nodal  links  for  UOC  and  CAC2S,  as  well  as  the  CoNDOR 
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communications  architecture.  The  table  below  gives  the  Pros  and  Cons  of  eaeh 
technology  (Table  1).  This  table  was  the  foundation  for  the  recommendation  matrix  seen 
below. 


FSO 

LOS 

Fiber  throughput  speeds,  quick  setup  time, 
operates  in  license  free  spectrum 

Susceptible  to  weather  conditions, 
short  distance  (<  5  km),  laser  alignment 

MICROWAVE  (RFM) 

LOS 

Up  to  OC-3  speeds,  already  packaged, 
reaches  out  to  13  kilometers 

Obtain  authorization  for  frequency  use, 
susceptible  to  interception  due  to  RF  use 

802.16 

LOS 

Adaptive  modulation,  up  to  66  Mbps, 

360  degree  coverage  out  to  20  km 

No  built-in  encryption,  company  evaluated  was 
ATM  based  (there  are  others  IP  based) 

802.11b  over  SecNet-11 

LOS 

Type  1  encryption  built-in, 
send  up  to  secret  level  data,  small  footprint 

Low  throughput  of  1-2  Mbps,  difficult  to  configure, 
not  compatible  with  other  802.1 1  b 

OFDM 

BLOS 

Communicates  over  hills,  through  trees,  and 
around  buildings,  25  Mbps  throughput 

Limited  encryption  built  in, 
need  good  azimuth  for  BLOS  connectivity 

BROADBAND  SATELLITE 
(Segovia/Omega  Systems) 

BLOS/OTH 

Large  throughput  capabilities  of  up  to  9  Mbps, 
mountable  on  a  vehicle.  Type  1  encryption 

Annual/Monthly  Fees,  but  not  by  minute 

INMARSAT 

(Nera) 

BLOS/OTH 

Satellite  connectivity  on-the-move, 
small  mountable  vehicle  platform,  encryption 

Expensive  per  minute  fees, 
low  throughput  of  56  Kbps  (working  on  upgrades) 

IRIDIUM 

BLOS/OTH 

Capable  of  combining  four  channels, 
comms  on-the-move,  no  monthly  fees 

Low  throughput  of  2.4  Kbps  per  channel, 
difficult  to  send  data  without  compression 

Table  1.  TECHNOLOGY  SUMMARY 


The  ultimate  goal  of  this  researeh  was  to  introduce  different  teehnologies  that 
offer  more  flexibility,  mobility,  and  capability  at  the  taetical  level  giving  the  Marine 
Corps  the  taetieal  wireless  edge.  During  the  Field  Tests  condueted  for  this  researeh 
projeet,  the  strengths  and  adaptability  of  the  various  produets  were  assessed.  The 
reeommendations  on  how  to  best  implement  these  teehnologies  for  UOC,  CAC2S,  and 
CoNDOR  are  given  in  the  table  below  (Table  2). 
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Table  2.  RECOMMENDATION  OF  WIRELESS  TECHNOLOGIES 


The  authors  decided  to  combine  the  UOC  and  CAC2S  recommendations  together 
since  the  command  and  control  systems  have  similar  distance  requirements  when 
physically  deployed  on  the  battlefield  and  the  requirements  for  communications  on-the- 
move  are  very  much  alike.  CoNDOR’s  recommendations  were  kept  separate  since  it  is 
not  a  command  and  control  system  but  rather  a  concept  of  connecting  multiple  echelons 
of  command  together.  For  UOC  and  CAC2S,  there  are  four  functional  areas  that 
communications  requirements  can  fall  under:  intra-nodal,  inter-nodal,  communications 
on-the-move,  and  aerial  relay.  The  CoNDOR  concept  revolves  around  the  Point  of 
Presence  Vehicle  (POP-V)  so  the  functional  areas  were  outlined  as  follows:  into  POP-V, 
out  of  POP-V,  communications  on-the-move,  and  aerial  relay. 


UOC/CAC2S 

By  utilizing  wireless  technologies  to  link  a  Command  Center  to  Antenna  Hill 
within  a  UOC  node  or  from  Processing  and  Display  Subsystem  (PDS)  to 
Communications  Subsystem  (CS)  and  Sensor  Data  Subsystem  (SDS)  in  a  CAC2S  node, 
the  Marine  Corps  could  potentially  replace  fiber  cables  that  run  between  the  sites.  The 
intra-nodal  setup  is  divided  into  two  different  categories  for  communications,  LOS  and 
BLOS.  The  LOS  technologies  researched  for  the  intra-nodal  setup  in  the  order  of 
recommendation  are  as  follows:  Free  Space  Optics  (FSO),  Microwave,  Orthogonal 
Frequency  Division  Multiplexing  (OFDM),  802.16,  and  802.1  lb  over  SecNet-1 1.  FSO  is 
the  right  fit  for  this  short  distance  of  less  than  2  kilometers  due  to  its  capabilities  shown 
in  Table  1  above.  OFDM  was  researched  and  evaluated  over  the  period  of  this  thesis 
work.  It  has  tremendous  capabilities  of  being  placed  in  valleys  near  Antenna  Hill  where 
it  can  be  camouflaged  without  inhibiting  the  capacity  of  the  link.  The  authors  saw 
throughput  up  to  25  Mbps  when  in  non-line-of-sight  situations. 

Since  the  distances  between  UOC  and  CAC2S  nodes  are  unpredictable  due  to  the 
frequent  movement  of  units  on  the  battlefield,  line-of-sight  (LOS),  beyond  line-of-sight 
(BLOS),  and  over-the-horizon  (OTH),  could  all  be  encountered  at  any  given  time.  In 
order  of  ranking,  the  following  technologies  are  recommended  for  use  in  LOS  situations 
for  the  inter-nodal  scenario:  OFDM,  802.16,  Microwave,  FSO,  and  802.11b  over 
SecNet-ll.  OFDM  is  best  suited  for  this  type  of  setup  since  it  is  the  most  forgiving  of 
the  technologies  if  ideal  LOS  is  not  attained.  While  all  of  the  LOS  technologies  become 
more  and  more  incapable  of  reaching  BLOS  distances,  OFDM  can  operate  in  LOS  or 
BLOS  situations.  This  makes  the  technology  the  number  one  recommendation  for  inter- 
nodal  BLOS  scenarios.  OFDM  will  maintain  connectivity  over  hills,  through  trees,  and 
around  buildings.  These  are  the  rankings  for  OTH  communications  in  the  inter-nodal 
scenario:  Broadband  satellite,  INMARSAT,  and  Iridium.  Broadband  satellite  provided 
by  Segovia/Omega  Systems  can  replace  the  TRC-170  setup  for  CAC2S  with  its 
capabilities  to  reach  up  to  9  Mbps,  and  it  is  comparable  in  size  with  the  SMART-T 
system,  but  could  provide  more  throughput  capability  for  the  UOC  node. 


xxn 


OFDM  is  the  first  recommendation  for  communications  on-the-move  within  a 
convoy  because  LOS  does  not  need  to  be  maintained  while  the  vehicles  are  moving. 
Each  vehicle  can  remain  a  safe  distance  away  from  the  others,  which  ensures  a  good 
security  posture.  While  the  distance  and  terrain  can  vary  greatly  when  communicating 
from  a  UOC/CAC2S  forward  echelon  convoy  back  to  the  main,  some  type  of  satellite 
connectivity  that  can  function  on-the-move  will  be  needed.  INMARSAT  is 
recommended  ahead  of  Iridium  due  to  its  throughput  capabilities. 

The  use  of  aerial  relays  for  UOC  and  CAC2S  nodes  can  greatly  increase  inter- 
nodal  communications.  This  could  be  an  alternative  to  the  MRC-142  or  TRC-170,  as  the 
802.11b  over  SecNet-11  could  be  retransmitted  via  the  airborne  platform  for  hundreds  of 
miles  if  the  signal  was  amplified  and  appropriate  antennas  were  utilized.  If  it  is 
determined  that  OFDM  can  be  amplified,  then  distance  could  equal  that  of  802.1  lb  and 
greater  flexibility  is  attained  on  where  antennas  would  need  to  be  placed  on  the  ground  to 
maintain  connectivity  with  the  airborne  platform. 

CoNDOR 

The  current  plan  for  the  CoNDOR  scenario  is  to  place  a  Point  of  Presence  Vehicle 
(POP-V)  at  the  battalion  level  to  further  enhance  the  capabilities  of  the  subordinate  units 
with  low  throughput  capabilities.  This  vehicle  will  allow  those  units  with  EPLRS, 
SINCGARS,  HF,  HF  Automatic  Link  Establishment  (ALE),  and  UHF  SATCOM  to  have 
access  to  Major  Subordinate  Commands  (MSCs)  through  the  satellite  connectivity  at  the 
battalion  level. 

The  LOS  recommendations  for  the  communications  into  the  POP-V  resemble  the 
LOS  rankings  used  for  UOC  and  CAC2S.  Since  EPLRS  is  currently  the  best  form  of 
data  connectivity  down  to  the  lower  levels  at  56  Kbps,  it  is  obvious  that  the  technologies 
recommended  would  bring  a  new  kind  of  capability  down  to  the  lowest  level.  The 
following  technologies  are  recommended  for  LOS  into  the  POP-V  in  the  order  of 
preference:  FSO,  Microwave,  OFDM,  802.16,  and  802.11b  over  SecNet-11.  For  BLOS 
situations  when  communicating  from  the  lower  echelons  to  the  POP-V,  the  following 
technologies  are  recommended  in  order  of  preference:  OFDM,  Broadband  Satellite, 


INMARSAT,  and  Iridium.  OFDM  can  become  the  teehnology  of  the  future  for  the 
Marine  Corps  if  it  ean  be  properly  enerypted  in  a  eost  effeetive  manner. 

When  communieating  from  the  POP-V  to  an  MSC,  the  seenario  will  most  likely 
require  some  form  of  BLOS  or  OTH  conneetivity.  In  a  BLOS  situation,  the  following 
technologies  are  reeommended  in  the  order  of  the  authors  preferenee:  OFDM, 
Broadband  satellite,  INMARSAT,  and  Iridium.  OFDM  ean  provide  a  terrestrial 
eonneetion  up  to  20  kilometers.  The  three  teehnologies  ranked  for  OTH  eapability  are 
Broadband  satellite,  INMARSAT,  and  Iridium.  Segovia/Omega  Systems  Broadband 
satellite  connectivity  during  Field  Test  Four  was  most  impressive.  They  are  able  to  vary 
the  amount  of  throughput  that  is  needed  and  can  provide  private  network  capabilities, 
Internet  serviees,  and  phone  serviees.  Their  link  can  also  be  Type  1  enerypted,  whieh 
eould  provide  SIPRNET  eonnectivity. 

Communications  on-the-move  is  what  the  CoNDOR  arehitecture  is  built  around. 
The  following  are  the  recommendations  in  order  of  priority  for  communications  within 
the  eonvoy:  OFDM,  802.11b  over  SeeNet-11,  and  Iridium.  OFDM  will  again  provide 
suffieient  bandwidth  for  a  platoon/eompany- sized  unit,  enable  a  small  footprint,  and 
allow  vehicles  flexibility  on  where  to  loeate  in  a  eonvoy.  If  there  is  a  company  or  platoon 
size  unit  that  is  traveling  in  a  convoy,  then  they  need  to  have  some  means  of  maintaining 
eonneetivity  to  the  POP-V  in  order  to  be  conneeted  with  all  other  units  associated  with 
that  POP-V.  INMARSAT  is  the  first  reeommendation  due  to  its  strength  of  the  on-board 
satellite  terminal  being  able  to  track  the  airborne  satellite  while  in  motion. 

The  use  of  aerial  relays  for  CoNDOR  can  greatly  increase  the  ability  to 
eommunicate  from  units  to  the  POP-V  and  from  the  POP-V  to  MSCs.  This  eould  be  an 
alternative  to  relying  on  LOS  radios  or  satellite  communications.  Two  technologies 
examined  in  this  thesis  are  recommended  for  use  in  the  aerial  relay  platform,  and  they  are 
802.1  lb  over  SecNet-1 1  and  OFDM. 

Bulk  encryption  was  utilized  at  General  Dynamies  and  Raytheon.  The  KG-235 
In-Line  Network  Eneryptor  proved  eompatible  with  FSO,  Microwave,  and  OFDM,  and  it 
could  definitely  work  with  the  other  teehnologies.  Detailed  analysis  needs  to  be  done  on 
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how  to  configure  the  eneryptor  appropriately  for  maximized  throughput  and  where  to 
place  the  KG-235  into  the  loeal  area  network. 

In  eonclusion,  the  authors  introduced  different  teehnologies  that  offered  more 
flexibility,  mobility,  and  capability  for  communications  on  the  tactical  battlefield. 
Throughout  this  researeh,  the  focus  revolved  around  testing  equipment  and  network 
configurations  in  an  IP  network  in  order  to  demonstrate  a  tactieal  wireless  edge.  Speeial 
consideration  was  given  to  wireless  issues  for  the  UOC,  CAC2S,  and  CoNDOR 
programs,  whieh  could  improve  line-of-sight,  beyond  line-of- sight,  and  over-the-horizon 
communications  for  each  of  them.  These  new  teehnologies  will  transform 
communications  in  the  United  States  Marine  Corps  for  the  2U'  eentury. 
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I.  INTRODUCTION 

A.  DISCUSSION  OF  THE  PROBLEM 

The  purpose  of  this  research  was  to  introduce  a  Transformational 
Communications  Architecture  for  the  U.S.  Marine  Corps’  Unit  Operations  Center  (UOC); 
Common  Aviation  Command  and  Control  System  (CAC2S);  and  Command  and  Control 
On-the-Move  Network,  Digital  Over-the-Horizon  Relay  (CoNDOR). 

The  following  three  questions  address  the  main  issues  being  examined  in  this 

thesis: 

1.  Can  transformational  communications  technologies  alter  the  intra- 
nodal  communication  links  in  UOC  and  CAC2S  into  a  more  capable  and  robust 
signal? 

2.  Can  transformational  communications  technologies  provide  more 
effective  inter-nodal  communications  links  between  UOC  and  CAC2S  nodes  than 
current  legacy  equipment? 

3.  Can  transformational  communications  technologies  be  utilized  in  the 
CoNDOR  scenario? 

The  ultimate  goal  of  this  research  will  be  to  introduce  different  technologies  that 
offer  more  flexibility,  mobility,  and  capability  at  the  tactical  level  than  what  current 
legacy  equipment  provides.  These  new  technologies  could  provide  the  Marine  Corps 
with  a  tactical  wireless  edge. 

A  statement  made  by  Major  General  Stalder,  United  States  Marine  Corps,  Deputy 
Commanding  General  for  I  Marine  Expeditionary  Force  (MEF)  before  the  House  Armed 
Services  Committee  on  October  21,  2003  states  the  following  about  Operation  Iraqi 
Freedom  (OIF): 

In  order  to  support  the  C2  systems,  the  MEF  and  its  major  subordinate 
commands  incorporated  several  recently  fielded  communication 
technologies.  Among  these  were  the  Secure  Mobile  Anti-Jam  Reliable 
Tactical-Terminal  (SMART-T),  the  Tactical  Data  Network  (TDN) 
gateway,  the  Digital  Technical  Control  (DTC)  facility,  and  the  Deployable 
KU  Earth  Terminal  (DKET).  Overall,  these  new  technologies  were  a 
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great  success  story  and  contributed  significantly  to  the  MEF  and  Major 

Subordinate  Command  (MSC)  Commanders’  ability  to  command  and 

control  forces  in  combat.  i 

There  have  been  numerous  advances  in  satellite  communications  for  the  MSCs, 
but  this  thesis  research  will  dig  deeper  into  the  tactical  problem  within  the  MSCs. 
Several  units  and  agencies  on  the  battlefield  are  still  without  similar  types  of 
communication  means  and  lack  the  technology  to  effectively  communicate  in  the  new 
information  age. 

1.  Marine  Corps  Technology  Problem 

The  Marine  Corps  is  developing  new  command  and  control  systems  such  as  UOC 
and  CAC2S,  and  new  concepts  for  Marine  Expeditionary  Forces  to  bridge  the  gap 
between  Major  Subordinate  Commands  (MSC)  and  their  subordinate  units,  such  as 
CoNDOR.  If  the  Marine  Corps  continues  to  rely  on  legacy  communications  for  these 
programs,  the  technology  gap  will  widen  even  further  than  what  already  exists.  New 
technologies,  such  as  the  ones  researched  in  this  thesis,  need  to  be  seriously  considered  to 
keep  the  warfighter  one  step  ahead  of  the  enemy.  The  authors  will  look  at  UOC,  CAC2S, 
and  CoNDOR  and  how  to  improve  line-of-sight  (LOS),  beyond  line-of-sight  (BEOS), 
and  over-the-horizon  (OTH)  communications  in  intra-nodal  and  inter-nodal 
environments. 

For  a  command  and  control  system  setup  in  the  Marine  Aviation  Command  and 
Control  System  (MACCS),  the  Marine  Corps  currently  uses  fiber  optic  cable  to  connect 
different  sites  in  the  intra-nodal  scenario.  For  example,  from  Combat  Operation  Center 
(COC)  to  communications  site,  a  heavy-duty  fiber  optic  cable  is  run  from  one  vehicle  to 
another.  If  the  wire  is  not  buried,  it  becomes  vulnerable  to  elements  such  as  vehicles 
running  over  it  or  the  enemy  slashing  the  wire  to  sabotage  the  communications 
capabilities.  This  creates  a  significant  single  point  of  failure  if  multiple  cables  are  not  run 
between  the  sites.  For  the  Ground  Combat  Element  (GCE),  large  amounts  of  cable  (fiber 
and/or  multi-pair)  and/or  single  pair  field  wire  are  currently  used  to  remotely  connect  the 

1  Major  General  Stalder,  USMC,  Brief  to  House  Armed  Services  Committee,  Subcommittee  on 
Terrorism,  Unconventional  Threats  and  Capabilities,  21  October  2003. 
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radios  and  other  communications  assets  from  COC  to  antenna  hill.  Thus,  the  same 
vulnerabilities  exist  for  the  GCE  as  the  MACCS  agencies. 

Next,  for  inter-nodal  data  communications  the  MACCS  relies  upon  the  A/N 
MRC-142  and  the  A/N  TRC-170,  while  the  ground  units  rely  heavily  on  the  MRC-142. 
The  characteristics  of  the  MRC-142  (Table  3)  and  the  TRC-170  (Table  4)  can  be  found 
below. 


Frequency  ranqe 

1,350-  1.850  MHz 

Bandwidth 

100  (125  opHonal)  kHz 

Channel  rate 

144.  288.  and  576  kbps 

Output  power 

Low;  300mW  (25dBm) 

High:  3  W  (35  dbin) 

Frequency  Stability 

10  ppm 

Orderwire  channel 

Analog;  300-  3,400  Hz 

Digital;  16  kbps 

Table  3.  AN/MRC-142  CHARACTERISTICS2 


The  AN/MRC-142  is  also  generally  employed  at  or  above  the  regimental  level.  It 
serves  as  a  flexible,  reliable  voice  and  data  link  in  the  USMC  digital  switched  backbone 
system.  The  AN/MRC-142  has  a  range  of  35  miles,  operates  at  data  rates  up  to  576  Kbps, 
and  will  support  a  maximum  of  36  voice  channels.  The  AN/MRC-142’s  enhanced 
bandwidth  management  and  data  throughput  capabilities  will  enable  other  critical 
systems  such  as  the  Tactical  Data  Network  (TDN)  and  the  Advanced  Field  Artillery 
Tactical  Data  System  (AFATDS)  to  be  fiilly  integrated  into  Marine  Air-Ground  Task 
Force  (MAGTF)  operations  ashore.3 


Frequency  Ranqe 

4.4-  5.0  GHz 

Bandwidth 

3.5  or  7.0  MHz 

Transmitter  power 

1  kW 

Diversity 

Dual 

Data  Rates 

Up  to  4,608  kbps 

Channel  capacity 

Up  to  144  (inciLides  overhead) 

(at  32kbps) 

Table  4.  A/N  TRC- 1 70  CHARACTERISTICS4 

2  http://www.fas.org/man/dod- 1 0  l/usmc/docs/mef99/part-2.pdf  (April  2004). 

3  http://www.marcorsvscom.usmc.mil/sites/pmcomm/tnrcl42.asp  (April  2004) 

4  http://www.fas.org/man/dod- 1 0  l/usmc/docs/mef99/part-2.pdf  (April  2004). 
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The  AN/TRC-170  is  a  transportable,  self-enclosed  multi-channel  tropo-scatter 
terminal  capable  of  transmitting  and  receiving  digital  data  over  varying  distances  (up  to 
100  miles).  The  MAGTF  headquarters  and  Aviation  Combat  Element  (ACE)  will 
normally  use  it.  5 

From  the  tables,  the  data  rates  shown  are  relatively  low  for  the  MRC-142  and 
somewhat  sufficient  for  the  TRC-170  compared  to  what  will  be  needed  in  the  future. 
These  two  systems  are  fairly  large  and  require  their  own  generators  for  power.  The 
technologies  examined  in  this  thesis  will  definitely  complement  or  provide  more  refined 
options  than  the  MRC-142  and  TRC-170. 

In  the  CoNDOR  setup,  the  Marine  Corps  relies  on  its  current  inventory  of  radios 
to  provide  data  connectivity  down  to  the  company  level  and  below,  such  as  the  Portable 
Radio  Component  (PRC)-104,  PRC-119,  Mobile  Radio  Component  (MRC)-138,  MRC- 
145  and  Enhanced  Position  Location  Reporting  System  (EPLRS).  These  are  all  strictly 
LOS  radios  that  provide  between  2.4  -  56  Kbps  of  data  throughput.  All  of  these  radios 
are  eventually  going  to  be  phased  out  by  the  Joint  Tactical  Radio  System  (JTRS)  in  2008 
and  beyond.  JTRS  is  being  designed  to  provide  a  flexible  new  approach  to  meet  diverse 
warfighter  communications  needs  through  software  programmable  radio  technology. 
There  will  be  a  significant  increase  in  data  throughput  up  to  approximately  2  Mbps,  and 
JTRS  will  provide  reliable  multi-channel  voice,  data,  imagery,  and  video 
communications.  As  one  can  see,  the  process  of  getting  more  throughput  to  the 
battlefield  is  going  to  take  some  time  with  JTRS.  Even  when  JTRS  is  fully  fielded,  the 
technologies  evaluated  in  this  thesis  could  complement  the  abilities  of  JTRS  in  the 
CoNDOR  architecture. 

The  authors  will  look  at  UOC,  CAC2S,  and  CoNDOR,  and  how  to  improve  LOS 
and  BLOS  communications  in  intra-nodal  and  inter-nodal  environments  throughout  the 
thesis.  The  problem  statements  for  UOC,  CAC2S,  and  CoNDOR  below  will  help  further 
explain  the  reasons  for  conducting  this  research. 


5  http://www.marcorsvscom.usmc.mil/sites/pmcomm/trcl70.asp  (April  2004). 
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2.  Unit  Operations  Center  (UOC) 

The  UOC  is  a  modular,  scalable  and  mobile  Command  and  Control  System  built 
to  facilitate  faster  and  more  accurate  decision  making  by  Marine  operational  forces.  It  is 
currently  going  through  operational  testing  with  several  fleet  units. 

Battalion  and  Regiment  level  UOC  use  the  same  component.  Regiment  level 
UOC  has  a  requirement  to  support  a  Coalition  LAN  and  Video  Teleconference  (VTC) 
capability,  which  is  not  required  for  Battalion  level.  Also,  the  Regiment  must  support  15 
operators  vice  eight  in  the  Battalion,  and  have  two  Visual  Display  Systems.  To  provide 
the  additional  power,  tents,  heating,  and  cooling,  an  additional  Generator,  Environmental 
Control  Unit,  and  Tent  (GET)  trailer  is  required  at  Regiment.  See  Figure  1  for  more 
detail  of  the  setup.6 


Figure  1 .  UOC  CONFIGURATION  FOR  INTRA-NOD AL  SETUPS 


The  node-to-node  communication  between  UOCs  resembles  the  current  COC  to 
COC  connectivity.  Depending  on  the  level  of  command,  battalion  and  lower  still  rely  on 


6  General  Dynamics  Decision  Systems,  “UOC  Summary  Brief’,  2003. 
^  General  Dynamics  Decision  Systems,  “UOC  Summary  Brief’,  2003. 
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LOS  radios  and  UHF  Satcom,  while  regiment  and  above  use  the  MRC-142  and  satellite 
based  communications  means.  The  current  Marine  Corps  plan  is  to  connect  the  COC  and 
antenna  hill  via  cables  and  wires. 

The  Marine  Corps  understands  the  vulnerabilities  of  relying  on  LOS  radios  and 
MRC-142  for  data  and  voice  connectivity.  During  OIF  the  Marine  Corps  regiments  and 
divisions  relied  on  satellite  communications  to  maintain  connectivity.  One  of  these 
satellite  systems  was  the  Secure,  Mobile,  Anti-Jam,  Reliable  Tactical  Terminal  (SMART- 
T).  SMART-T  is  a  MILSTAR  satellite-compatible  communications  terminal  mounted  on 
a  High  Mobility  Multi-Purpose  Wheeled  Vehicle  (HMMWV).  It  allows  long-haul 
tactical  communications  for  Digital  Transmission  Groups  (DTG),  Digital  Subscriber 
Voice  Terminal  (DSVT),  and  individual  encrypted  subscribers,  at  data  rates  ranging  from 
75  bps  to  1.544  Mbps. 8 

Even  though  some  efforts  have  been  made  to  address  BLOS  issues  with  node-to- 
node  communications,  there  are  several  other  wireless  options  available  that  will  be 
brought  out  in  this  research.  Based  on  visits  by  the  authors  over  the  past  few  months  with 
the  UOC  offices  at  General  Dynamics  and  Marine  Corps  Systems  Command  (MCSC), 
intra-nodal  communications  via  wireless  technologies  are  not  included  in  the 
requirements  for  the  system  and  are  apparently  not  being  looked  at  seriously. 

3.  Common  Aviation  Command  and  Control  System  (CAC2S) 

The  current  MACCS  functions  with  a  Tactical  Air  Command  Center  (TACC), 
Direct  Air  Support  Center  (DASC),  Tactical  Air  Operations  Center  (TAOC),  Air  Traffic 
Control  (ATC),  and  Low  Altitude  Air  Defense  (LAAD)  command  and  control  centers. 
CAC2S  will  replace  these  legacy  systems  in  three  incremental  builds,  and  it  will  provide 
common  hardware  and  software  to  all  users  in  the  MACCS.  CAC2S  will  be  scalable,  so 
it  can  be  configured  for  air,  ground,  and  afloat  operations. 9 

The  MACCS  agencies  are  dispersed  throughout  the  battlefield  with  locations  and 
distances  being  very  unpredictable.  So,  the  current  structure  uses  a  combination  of 
MRC-142  and  TRC-170  systems.  The  MRC-142  is  strictly  LOS  and  the  TRC-170  can 

8  http://www.marcorsvscom.usmc.mil/sites/pmcotnm/smart  t.asp  (April  2004). 

9  Marine  Corps  Tactical  Systems  Support  Activity,  Program  Support  Division,  “CAC2S  Technical 
Briefing”,  13  February  2002. 
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extend  out  to  distances  of  100  miles  due  to  the  tropo  scatter  functionality  of  the  system. 
Since  there  are  not  enough  TRC-170s  for  each  node  located  throughout  the  battlefield, 
MRC-142s  are  employed  with  retransmission  sites  set  up  on  top  of  hills  or  mountains 
when  LOS  cannot  be  attained.  Figure  2  shows  how  CAC2S  is  planning  to  communicate 
when  the  systems  are  fielded  in  2007  and  beyond.  This  is  identical  to  how  the  current 
MACCS  communicates.  Thus,  one  can  see  the  dangers  of  not  upgrading  the 
communication  capabilities  with  the  new  system. 


Assumption: 

Engineering  Deveiopmental  Model 

(Based  on  the  As-ls  Marine  Air  Wing  Equipment  Lay  Down) 


Figure  2.  CAC2S  FOR  INTER-NODAL  AND  INTRA-NODAL  COMMUNICATIONS 

The  present  plan  between  Raytheon  (organization  assisting  the  Marine  Corps 
develop  CAC2S)  and  Marine  Corps  Systems  Command  is  to  continue  to  connect  the 
intra-nodal  sites  within  each  node  by  fiber  optic  cable.  For  example  at  the  Air  Support 
Node  (ASN)  node,  the  Processing  and  Display  Subsystem  (PDS)  will  be  connected  to  the 
Communications  Subsystem  (CS)  and  the  Sensor  Data  Subsystem  (SDS)  via  a  heavy- 
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duty  fiber  cable.  There  will  also  be  fiber  cable  runs  between  the  SDS  and  CS  sites.  This 
setup  provides  redundancy  between  all  the  sites,  but  it  still  is  vulnerable  and  relies  upon 
the  cumbersome  and  expensive  tasks  of  laying  and  burying  wire. 

4.  Command  and  Control  On-the-Move  Network,  Digital  Over  the 
Horizon  Relay  (CoNDOR) 

The  CoNDOR  Capability  Set  is  an  Architectural  Approach  designed  to  bridge 
battlefield  Command  and  Control  over  variable  distance,  either  LOS  or  over-the-horizon 
(OTH).  Figure  3  shows  a  CONDOR  point-of-presence  (POP)  vehicle.  It  will  facilitate 
communication  with  High  Frequency  (HF),  Very  High  Frequency  (VHF),  Ultra  High 
Frequency  (UHF),  UHF  Satcom,  and  EPLRS  radios.  As  JTRS  evolves  and  is  fielded, 
CoNDOR  will  be  able  to  integrate  these  radios  as  well.  Several  technologies  are  being 
evaluated  for  CoNDOR’ s  satellite  access  to  higher  headquarters  while  it  is  stationary  and 
on-the-move. 


Figured"”  CoNDOR  POP  VEHICLEIO 


One  problem  that  is  inherent  to  the  CoNDOR  setup  is  that  legacy  LOS  radios  and 
eventually  JTRS  are  being  relied  upon  to  provide  data  connectivity.  These  are  all  limited 
in  throughput  capabilities,  for  example  legacy  radios  are  less  than  56  Kbps  and  JTRS  is 
below  2  Mbps  of  throughput.  The  satellite  communications  system  currently  being 
looked  at  to  connect  the  POP  vehicle  to  higher  headquarters  is  also  limited  in  throughput 
(less  than  1  Mbps).  Several  technologies  evaluated  in  this  research  are  viable  options  to 


10  https://www.quickplace.marcorsvscom.usmc.mil/CoNDOR  (April  2004). 
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connect  the  CoNDOR  POP  vehicle  at  the  battalion  level  down  to  the  lower  levels  as  well 
to  connect  the  battalion  POP  vehicle  to  higher  headquarters  in  a  BLOS  or  OTH  situation. 

In  order  to  have  a  better  understanding  of  the  problem  statements  for  UOC, 
CAC2S,  and  CoNDOR,  detailed  background  information  is  given  on  each  program 
below.  The  authors  were  able  to  visit  each  of  the  respective  program  offices  at  MCSC. 
In  addition,  they  visited  Raytheon’s  CAC2S  and  General  Dynamics’  UOC  program 
offices  and  Space  and  Naval  Warfare  Command  (SPAWAR)  Charleston,  where  several 
personnel  are  working  with  MCSC  on  UOC,  CAC2S,  and  CoNDOR.  This  was  all  done 
for  first  hand  knowledge  of  the  programs  and  their  progress. 


B.  BACKGROUND  INFORMATION 

The  information  discussed  in  the  following  paragraphs  is  designed  to  give  the 
reader  a  general  understanding  of  the  programs  involved  in  this  thesis.  By  no  means  are 
the  authors  speaking  on  behalf  of  the  program  offices  mentioned  below. 

1.  UOC 

a.  Current 

The  UOC  is  designed  to  provide  Marine  operational  forces  with  command 
and  control  capabilities  whenever  and  wherever  Marines  operate  or  fight,  n  The  UOC  is 
to  provide  the  Ground  Combat  Element  (GCE)  commander  with  the  necessary  hardware, 
software,  equipment,  and  facilities  to  effectively  command,  coordinate,  and  control 
MAGTF  air  in  joint/multi-national  operations.  The  UOC  will  be  mobile,  expandable, 
scalable,  modular,  command  and  control  interoperable  system  in  a  HMMWV,  C-130,  or 
ship.  The  UOC  will  first  be  fielded  to  GCE,  followed  by  the  Command  Element  (CE), 
and  the  Combat  Service  Support  Element  (CSSE).  The  UOC  facilitates  command  and 
control  for  the  above  elements.  Figure  4  depicts  a  Marine  in  the  UOC.  Lieutenant 
Colonel  Tolbert  from  MCSC  best  captures  the  purpose  of  the  UOC: 

The  UOC  program  seeks  to  maximize  the  commander's  decision 
making  superiority  by  providing  digital  tools  and  a  fully  integrated 
Combat  Operations  Center  (COC)  that  uses  common  hardware 


1 1  UOC  summary  power  point  brief;  General  Dynamics 
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across  the  Marine  Corps.  This  will  result  in  increasing  unit 
efficiency  and  combat  effectiveness.  12 


Figure  4.  MARINE  IN  THE  UOC 


According  to  Headquarters  Marine  Corps,  “The  COC  will  provide  the 
servers  to  host  applications  required  by  the  commander.  These  applications  include  the 
Global  Command  and  Control  System  (GCCS),  Tactical  Combat  Operations  (TCO), 
Intelligence  Analysis  System  (IAS),  Advanced  Field  Artillery  Tactical  Data  Systems 
(AFATDS),  and  Theater  Battle  Management  Core  System  (TBMCS).  The  COC  will 
connect  to  the  Tactical  Data  Network  for  Digital  Message  System  (DMS)  services.”i3 

The  operational  impact  the  UOC  will  have  is  that  the  commander  and  the 
commander’s  staff  will  be  able  to  receive  a  Common  Tactical  Picture  (CTP)  via  data  and 
voice  communications.  The  UOC  will  have  the  capability  of  functioning  as  a 
reconfigurable,  scalar,  mobile,  and  deployable  command  and  control  system.  14  This 
capability  will  have  a  significant  impact  in  Marine  warfare  by  providing  the  foundation  to 
facilitate  command  and  control  on  the  battlefield. 


12  http://www.gdds. com/uoc/uoc  digitalcombat.html;  LtCol  Donald  D.  Tolbert,  Jr;  Unit  Operations 
Center:  The  Digital  Combat  Operations  Center  of  the  Future,  Reprinted  from  Marine  Corps  Gazette, 
January  2003. 

13  http://hqinet001  .hqmc.usmc.mil/p&r/concepts/2001/PDF/UOC.pdf 

14  Ibid 
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b.  Future 

The  UOC  is  configured  in  predefined  capability  sets  (CapSets).  There  are 
four  CapSets:  CapSet  I  is  configured  to  support  a  Marine  Expeditionary  Force,  CapSet  II 
is  configured  to  support  a  Division,  CapSet  III  is  configured  to  support  a  Regiment,  and 
CapSet  IV  is  configured  to  support  a  Battalion  (Figure  5).i5  The  estimated  completion 
date  for  the  initial  operational  capability  is  late  2004.  In  fiscal  year  2005,  twenty  more 
units  will  be  procured  in  order  to  support  Operation  Iraqi  Freedom  and  technology 
inserts.  16 


Core  Building  Blocks  Used  to  Build  All 
UOC  Capability  Sets 


Echelon 

Capability  Sets  (CAP  SETS) 

I 

II 

III 

IV 

Alpha 

MEF  (MEB 
BRAVO) 

MARFOR, 

FICCS, 

FSSG  CSSOC, 
DIV,  RGT 

MCSSD  (4),MSSG, 
BN,  MWSS,  MEU, 

GS  CSSD,  DS  CSSD 
(GCE),  DS  CSSD 
(FW)  2,  DS  CSSD 
(RW)2 

Bravo 

MEF 

DIV, FSSG 
CSSOC 

RGT,  MWSG, 
MEU,  GS  CSSD, 
DS  CSSD 

BN,  MAG,  MWSS, 
MACG, 
SUPPORTING 
ESTABLISHMENT 

Capability  Set  I 

Capability  Set  II  (Future) 

Capability  Set  III 

Capability  Set  IV 

Note:  HMMW^ 
these  four  Capal 
They  are  existin 
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Figure  5.  UOC  CAPABILITY  SETS 


The  UOC  is  designed  with  a  T3  design:  Tents,  Trailers,  and  Transit  Cases 
(Figure  6).  The  generator,  environmental  control  unit,  and  tent  are  located  on  the  GET 
(generator,  environmental  control  unit,  and  tent)  trailer.  1 7 


15  Detailed  UOC  power  point  brief;  General  Dynamics 

16  Conversation  with  Kevin  Holt,  USMC  UOC  team  leader,  MCSC 

17  Ibid;  General  Dynamics  power  point  presentation 
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Fast  Deployment 


UOC  is  designed  for  maximum  deployment 
flexibility  using  a  ‘T3’  design: 

Tents,  Trailers,  Transit  Cases 


T3  design  allows  a  wide  range  of  deployment  options 


Figure  6.  T3  DESIGN 


The  operational  trailer  (OT)  is  the  key  component  in  the  T3  design.  The 
operational  trailer  has  a  rack  structure  that  supports  and  provides  a  secure  network,  a  non- 
secure  network,  uninterrupted  power  supply,  eight  operator  workstations,  intercom, 
public  address  system,  and  on-the-move  capability  (via  EPLRS,  VRC-92,  and  PSC-5). 
The  transit  cases  do  not  need  to  be  removed  from  the  trailer,  hence,  reducing  the  setup 
time.  The  transit  cases  are  interconnected  with  cable  harnesses  that  are  permanently 
installed  on  the  rack.  All  cable  connectors  are  accessible  either  from  the  front  of  the 
equipment  or  from  the  rear  with  sufficient  cable  service  loops.  The  supplemental 
equipment  provides  a  repeatable  load  plan  and  the  capability  of  reusable  harnesses  and 
straps. 

2.  CAC2S 

a.  Current 

This  program  is  to  provide  the  Aviation  Combat  Element  (ACE) 
commander  with  the  necessary  hardware,  software,  equipment,  and  facilities  to 
effectively  command,  coordinate,  and  control  MAGTF  air  in  joint/multi-national 
operations.  CAC2S  is  a  mobile,  expandable,  scalable,  modular,  full  command  and 
control  interoperable  system  in  a  Highly  Mobility  Multi-Purpose  Wheeled  Vehicle 
(HMMWV),  C-130  aircraft,  or  ship.  CAC2S  provides  a  common  operational  picture  for 
air  operations,  weapons  control,  communications,  sensors,  and  other  displays.  The  key 
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feature  of  the  program  is  that  it  functionally  replaces  dissimilar  stovepipe  systems 
currently  utilized  by  the  Marine  Aviation  Command  and  Control  System  (MACCS). 
Additional  features  are  that  it  reduces  the  footprint  and  lift,  while  providing  a  complete 
and  coordinated  modernization  effort  capable  of  supporting  Expeditionary  Maneuver 
Warfare  (EMW).i8  See  Figure  7  for  illustration. 


Figure  7.  CAC2S  OVERVIEW 


CAC2S  provides  the  means  to  revolutionize  the  equipment  base  and 
operational  concepts  of  the  MACCS  to  support  Operational  Maneuver  From  the  Sea 
(OMFTS).  CAC2S  will  provide  the  MAGTF  commander  with  the  mission  critical 
support  system  required  to  integrate  aviation  and  ground  combat  operations  in  support  of 
the  Marine  Corps’  operational  objective.  CAC2S  will  provide  the  ACE  commander  and 
battle-staff  with  the  capability  to  communicate  with  higher,  adjacent,  and  subordinate 
units,  as  well  as  the  ability  (through  subordinate  MACCS  agencies)  to  exercise  real-time 
positive  control,  coordination,  and  direction  of  MAGFT  and  joint  air  assets.  CAC2S 
components  will  operate  from  aerial  platforms,  amphibious  shipping  and  from  C2 

18  CAC2S  SFR  Brief:  October  21-22,  2003 
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agencies  ashore.  In  other  words,  CAC2S  will  operate  on  land,  at  sea,  or  from  the  air  to 
support  Marine  Corps  war  fighting  concepts  for  the  21st  Century.  19 


CAC2S  provides  an  operational  impact  in  conjunction  with  MACCS 
organic  sensors  and  weapon  systems  in  order  to  support  the  tenets  of  Expeditionary 
Maneuver  Warfare  and  fosters  joint  interoperability  with  Department  of  Defense’s 
command  and  control  systems.  CAC2S  will  replace  legacy  C2  systems  in  the  following 
Marine  aviation  C2  elements:  Tactical  Air  Operations  Center  (TAOC),  Tactical  Air 
Command  Center  (TACC),  Direct  Air  Support  Center  (DASC),  Marine  Air  Traffic 
Control  Detachment  (MATCD),  and  Low  Altitude  Air  Defense  Battalion  (LAAD  BN).20 
b.  Future 

CAC2S  will  be  comprised  of  modules  and  subsystems.  Hardware 
components  for  CAC2S  will  be  modular  and  man-portable.  According  to  Marine  Corps 
Tactical  Systems  Support  Activity  (MCTSSA): 

The  CAC2S  modules  are  scalable  to  meet  mission  requirements. 

The  modules  will  be  assembled  to  create  an  operational  node.  The 
core  software  of  the  CAC2S  will  include  all  of  the  functions 
common  to  all  current  MACCS  agencies,  including  the  ACE 
requirement  for  aviation  C2  planning.  Mission  unique  functions 
will  be  configurable  and  selectable  from  every  workstation.  The 
CAC2S  will  interface  with,  but  not  replace,  radios,  air  defense 
weapons,  and  sensors  organic  to  the  MACCS. 21 

The  Raytheon  estimated  completion  date  for  the  initial  operational 
capability  is  February  2007.  The  program  status,  according  to  the  CAC2S  brief,  is  as 
follows: 


The  CAC2S  and  UOC  programs  are  being  developed  in  parallel  to 
eventually  achieve  a  common  MAGTF  Operations  Center  solution. 
CAC2S  is  being  developed  in  an  evolutionary  acquisition  strategy 
in  four  increments.  Increment  I  will  replace  the  functionality  of 
the  TAOC  and  will  baseline  the  core  information  fusion  and 
management  function  common  to  all  increments  and  eventually  all 
MAGTF  Operation  Centers.  Increment  II  will  replace  TACC  and 
DASC  nodes.  Increment  III  will  achieve  integration  between 

19  Power  point  brief;  MCTSSA  CAC2S  BRIEF  13  FEB  02 

20  http://hqinet001  .hqmc.usmc.mil/p&r/concepts/2000/PDFs/Chapter4/ch4_pl_l  l_CAC2S.pdf 

21  http://www.mctssa.usmc.mil/PSD/CAC2S%20fact%20sheet.pdf 


14 


CAC2S  and  the  Air  Surveillance  and  Precision  Approach  Radar 
Control  System  (ASP ARCS)  for  Air  Traffic  Control  functionality. 
Increment  IV  is  the  transition  to  the  complete  MAGTF  Operation 
Center  functionality.  CAC2S  is  an  ACAT  III  program  currently  in 
the  definition  and  risk  reduction  development  phase. 22 

MCTSSA  captures  the  different  increments  in  Figure  8. 


CAC2S  Incremental  Approach 


Increment  I  -  Hardware  and 
software  replaeement  for  the  eore 
MACCS  requirements  and  the 
Taetieal  Air  Operations  Center 

(TAOC)  flinetionality 

Increment  II  -  Taetieal  Air 
Command  Center  (TACC) 
flinetionality  and  the  Direet  Air 
Support  Center  (DASC) 
flinetionality 

Increment  HI  -  Marine  Air  Traffie 
Control  (ATC)  C2  Integration 

Increment  IV  -  MAGTF  OC 
flinetionality 

Marine  Corps  Tactical  Systems  Support  Activity,  Program  Support  Division 


Figure  8.  CAC2S  INCREMENTAL  APPROACH 


3.  CONDOR 

a.  Current 

According  to  MCSC,  “CoNDOR  capability  set  is  a  program  of  record  that 
provides  the  ability  to  link  dispersed  OTH  and/or  BEOS  operators. ”23 

In  order  to  better  understand  CoNDOR,  the  reader  needs  to  understand 
how  Marine  Corps  communications  works.  Marine  Expeditionary  Force  (MEF)  and 
MSCs  like  the  Division,  Wing,  and  Force  Service  Support  Group  Headquarters  have 
historically  had  reliable  connectivity.  The  MEF  and  MSCs  have  been  connected  via  large 
satellite  networks.  Telephone  connectivity,  a  military  version  of  public  switched 
telephone  network,  is  then  built  into  the  satellite  networks.  Data  connectivity  for 

22  www.hqinetOO  1  .hqmc.usmc.mil/p&r/concepts/2002/PDF/CH3_Part3/ch3%20part%203%20CAC2S.pdf 
23  Lieutenant  Colonel  J.D.  Wilson,  “Draft  CoNDOR  C4ISP”,  MCSC,  March  2004 
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classified  and  unclassified  networks  is  provided  via  a  Tactical  Data  Network,  which 
usually  uses  the  satellite  links.  The  major  limitations  for  MEF  and  MSCs  are  the  lack  of 
satellite  throughput  available  to  support  the  high  bandwidth  demand  and  the  loss  of 
communications  when  the  MSC  commander  displaces  to  a  new  location.24 

The  infrastructure  for  maneuvering  commands  like  Companies,  Batteries, 
or  mobile  Combat  Service  Support  Detachments,  is  limited  to  LOS  radios  and  small 
amounts  of  bandwidth  availability.  These  limited  communications  are  means  by  which 
the  maneuvering  commands  communicate  to  their  Battalions,  Regiments,  or  higher 
headquarters.  Data  travels  across  the  battlefield  via  EPLRS,  or  through  a  point-to-point 
system  using  modems  such  as  ViaSat.  Once  the  information  reaches  the  MSC  level,  it  is 
passed  along  the  MSC  communication  links.  The  major  limitations  have  been  the  limited 
bandwidth  provided  by  the  tactical  radios  and  the  lack  of  an  OTH  capability.  Through 
the  efforts  of  the  Office  of  Naval  Research  (ONR)  and  MCTSSA  connectivity  for  the 
maneuver  forces  from  the  ship  to  the  objective  area  has  been  provided  by  a 
communications  bridge  via  the  CoNDOR  gateway  (Figure  9).  The  CoNDOR  gateway 
uses  EPLRS  to  establish  the  communications  bridge,  but  there  are  units  that  do  not  have 
EPLRS.  For  these  units  a  Point  of  Presence  Vehicle  (POP-V)  provides  connectivity  to 
the  MSC.  The  data  is  very  limited  however,  due  to  the  throughput  of  the  tactical  radio,  as 
described  in  the  problem  statement  above. 


24  Lieutenant  Colonel  J.D.  Wilson,  “CoNDOR  Overview”,  MCSC,  power  point  presentation  March 
2004 
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CONDOR  “Gateway’ 


The  CONDOR  Gateway: 

Purpose:  Connects  EPLRS  Communities  over  distance. 

-EPLRS  Node 
-C2PC  Gateway 

-Over  the  Horizon  connection  (INMARSAT,  Iridium,  TACSAT) 


EPLRS  Community 


But  what  can  we  provide 
for  the 

Units  that  do  not  have 
EPLRS? 


EPLRS  Community 


Figure  9.  CONDOR  GATEWAY 


b.  Future 

The  CoNDOR  gateway  consists  of  an  EPLRS  node,  a  Command  and 
Control  Personal  Computer  (C2PC)  gateway,  and  OTH  connectivity  (INMARSAT, 
Iridium,  or  TACSAT).  In  a  PoP-V  the  gateway  will  consist  of  tactical  radios 
(SINCGARS,  Have  Quick  II,  TACSAT  DAMA,  HF,  HF  ALE,  EPLRS),  C2PC  gateway, 
and  OTH  connectivity  (Figure  10). 
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The  CoNDOR  PoP-V  will  provide  the  capability  of  extending  the  network 
via  tactical  radios.  Additionally,  the  CoNDOR  PoP-V  will  give  insight  on  how  to 
configure  the  architecture  for  the  Joint  Tactical  Radio  System  (Figure  1 1). 


Put  the  capability  where  it 

is  needed  : 


Figure  1 1 .  USMC  JTRS  CONDOR  POP-V 


Integration  capabilities  for  CoNDOR  are  being  conducted  in  a  universal  communications 
interface  module  (UCIM).  The  UCIM  is  a  modular  component  set  that  will  configure 
vehicular  power  to  communications  systems;  load  and  configure  all  radios  (legacy  and 
JTRS);  load  and  tune  the  antennas;  provide  a  keyboard,  video,  and  mouse  functionality 
from  any  seat;  provide  a  central  processing  unit  to  host  applications  (C2PC  gateway, 
SPEED,  etc.);  and  create  an  enclave,  coupling  C2  systems  with  radios.  Other  capabilities 
are  being  developed  in  a  CoNDOR  JUMP  C2.  In  the  CoNDOR  JUMP  C2,  the 
commander  will  have  continuous  connectivity  even  when  the  unit  displaces  from  one 
location  to  another.  The  continuous  connectivity  increases  situational  awareness  and 
enhances  the  commanders’  command  and  control  capabilities  (Figure  12). 
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A  CONDOR  “Jump  C^”  ^ 


The  CONDOR  Jump  Vehicle: 

Purpose:  Maintains  COP/SA  during  Displacement 
-Downsized  JECCS  Capability 
-SIPRNet 
-NIPRNet 

-Telephone  Wireless  Technoloev 

-VTC 


Beyond 
Line  of  Sight 


Jnmp 
Command  Vehicle 


Figure  12.  CONDOR  JUMP  C2 


This  section  discussed  the  background  of  the  programs  that  are  addressed 
in  this  thesis.  The  following  sections  will  further  explain  the  statement  of  the  problem 
and  the  methodology  used  to  approach  it. 
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II.  RESEARCH  METHOLOGY  AND  FIELD  TESTS 


Multiple  technologies  were  evaluated  for  potential  use  in  three  Marine  Corps 
programs:  UOC,  CAC2S,  and  CONDOR.  The  authors  used  a  “building  block”  approach 
to  become  familiar  with  the  research  topic  and  available  technologies  in  the  commercial 
sector. 

First,  the  authors  visited  Marine  Corps  Systems  Command,  Space  and  Naval 
Warfare  Systems  Command  -  Charleston,  Office  of  Naval  Research,  Marine  Corps 
Warfighting  Laboratory,  and  Marine  Corps  Tactical  Systems  Support  Activity  to  become 
familiar  with  the  Marine  Corps  programs  and  current  research  being  conducted.  In 
addition,  the  authors  visited  private  company  laboratories  to  observe  applicable 
technologies  working  in  an  operating  environment.  Finally,  the  authors  visited  the  UOC 
program  office  at  General  Dynamics  Decision  Systems  (GDDS)  in  Scottsdale,  AZ  and 
the  CAC2S  program  office  at  Raytheon  in  San  Diego,  CA  to  become  familiar  with  the 
research  being  done  by  government  contractors  to  exploit  the  wireless  communications 
industry. 

Following  these  visits,  four  field-testing  events  were  planned  over  a  five-month 
period  starting  in  November  and  ending  in  March.  The  field  events  began  with  a 
“backyard  exercise”  in  the  Monterey,  CA  area  to  become  familiar  with  various  network 
configurations  and  some  of  the  technologies  being  evaluated.  Next,  in  January,  the 
authors  traveled  down  to  GDDS  to  work  with  the  UOC  team  and  demonstrate  the 
different  technologies  to  them.  The  authors  then  went  to  Raytheon  in  February  in  order 
for  the  CAC2S  team  to  see  what  technologies  were  available  for  possible  intra-nodal  and 
inter-nodal  communications.  Finally,  in  March  the  authors  traveled  to  Camp  Roberts, 
CA  to  conduct  a  realistic  field-testing  event  that  simulated  a  CONDOR  scenario.  In 
order  to  facilitate  the  research  the  authors  utilized  the  Naval  Postgraduate  School’s 
Mobile  Research  Facility  (MRF).  This  is  a  33-foot  Recreational  Vehicle  that  was 
converted  into  a  mobile  Network  Operations  Center.  Connectivity  was  tested  from  this 
platform  in  order  to  simulate  Command  Center  to  Antenna  Hill  and  CAC2S  node  to 
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CAC2S  node  links.  The  data  obtained  from  these  testing  events  was  used  by  the  authors 
to  evaluate  various  commercial  technologies  for  potential  use  in  Marine  Corps 
operations. 

Marketing  and  technical  literature  from  all  the  companies  were  also  reviewed  to 
include  system/subsystem  specifications,  test  evaluations,  and  engineer  assessments. 

Finally,  the  visits  to  program  offices  and  private  companies,  was  combined  with 
the  testing  and  document  research,  to  formulate  recommendations  for  future  UOC, 
CAC2S,  and  CONDOR  communications  architectures. 

A.  FIELD  TEST  #1  (FORT  ORD  AND  BIG  SUR,  CA) 

The  purpose  of  the  first  experiment  was  to  become  familiar  with  Free  Space 
Optics  (FSO)  Equipment  and  802. 1 1  link  equipment  in  order  to  establish  a  baseline  for 
follow-on  testing  for  transformational  wireless  communications  technologies  for  UOC, 
CAC2S,  and  CoNDOR.  The  methodology  used  was  to  establish  two  Local  Area 
Networks  (LANs),  one  at  a  fixed  site  (Figure  13)  and  one  at  the  MRF  (also  known  as 
Nemesis).  These  two  LANs  were  then  linked  using  two  different  FSO  systems,  (fSONA 
17  &  18  November  and  Lightpointe  20  &  21  November).  802.11  wireless  technology 
was  also  used  during  both  test  periods.  These  tests  are  described  in  the  sections  that 
follow. 
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Figure  13.  FIXED  SITE  AT  BIG  SUR 


Some  of  the  anticipated  results  were  to  be  able  to  develop  a  more  thorough 
understanding  of  the  limitations,  set  up,  throughput,  and  mobility  of  FSO  and  establish  a 
methodology  for  future  experiments.  This  was  a  “kick  the  tire”  experiment  where  the 
primary  focus  was  to  establish  a  wireless  link  between  two  sites  and  gather  information 
such  as  power,  special  connectors,  and  logistical  requirements  in  order  to  conduct  an 
experiment. 

1.  Line-of-Sight  (LOS) 
a.  fSONA 

fSONA  specializes  in  Free  Space  Optics  communications.  The  company 
is  based  in  British  Columbia,  Canada.  This  FSO  company  was  eager  to  assist  during  this 
testing  event,  as  well  as  each  of  the  others.  Their  team  consisted  of  the  following  people: 
Mike  Corcoran,  Vice  President  Sales;  Grant  Merkley,  Inside  Sales;  Pablo  Bandera, 
Product  Manager;  and  Sean  Dante,  Field  Technician.  The  Naval  Postgraduate  School 
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(NPS)  students  primarily  involved  were  Captain  Gilbert  Garcia  (USMC),  Captain  David 
Joseforsky  (USMC),  Lieutenant  Albert  Seeman  (USN),  and  Lieutenant  Jesus  (Manny) 
Cordero  (USN). 

Testing  was  conducted  on  November  17-18,  2003  for  fSONA.  On  17 
November,  a  test  was  conducted  at  a  distance  of  580  meters  in  an  urban  environment  at 
Fort  Ord,  California,  and  on  18  November  testing  was  conducted  at  Big  Sur,  California, 
in  order  to  establish  a  longer  link  (850  m)  than  the  one  used  at  Fort  Ord.  The  equipment 
used  was  the  SONAbeam  155-M  model  (Figure  14),  which  delivered  an  OC-3  data  rate 
(155Mbps),  but  during  the  experiment  the  link  was  running  at  Fast  Ethernet  speeds  (100 
Mbps).  This  product  provides  a  full  duplex  transmission  at  the  physical  layer  with  four 
independent  lasers,  drivers,  coolers,  and  cooler  controllers.  It  comes  with  a  cast 
aluminum  housing,  yoke,  and  mount.  The  fiber  optic  interface  is  a  Single-Mode  or 
Multi-Mode  fiber,  SC  terminated.  The  SONAbeam  155-M  system  was  designed  to 
mount  to  any  vertical  pole  of  diameter  2.5"  to  4.5".  The  FSO  transceivers  were  set  up  on 
a  ten-foot  steel  pole  with  three  legs  to  stabilize  the  pole.  Each  leg  and  the  pole  weighed 
roughly  fifty  pounds.  This  allowed  the  FSO  link  to  be  very  stable.  These  pole  mounts 
were  not  fSONA's,  and  were  actually  bigger  than  they  really  needed  to  be.  Other  means 
are  being  explored  by  fSONA  to  find  a  mount  that  is  more  field  expedient  and  suitable 
for  the  Marine  Corps. 
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Figure  14.  SONABEAM  155M  MODEL 


The  weather  conditions  for  this  testing  were  ideal,  with  clear  skies  and 
calm  winds.  Figure  15  depicts  an  overview  of  the  LAN  configuration  showing  the 
physical  layout  of  the  testing  equipment  and  the  IP  addresses  for  each  piece  of  gear  in  the 
network. 
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Overall  View  Nov  17-18 
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Solar  Winds  Laptop  Dave  VoIP  Phone 


Figure  1 5 .  OVERVIEW  DIAGRAM  fSONA  EXPERIMENT 


fSONA  representatives  set  up  fSONA’s  FSO  equipment.  On  17 
November,  they  demonstrated  the  setup  of  the  equipment  and  also  showed  the  NPS  team 
how  to  align  the  link.  The  total  set  up  time  was  one  hour  including  a  detailed  explanation 
to  the  users  on  how  to  set  up  the  gear  properly.  Seasoned  field  technicians  from  fSONA, 
on  previous  occasions,  have  set  up  the  gear  and  had  it  operational  within  30  to  45 
minutes. 

Each  day,  media  converters  were  placed  between  the  FSO  link  and  the 
WAN  switches  because  the  Cisco  2950  switches  being  used  did  not  have  the  appropriate 
interface  to  connect  directly  to  the  FSO  link.  Single-mode  fiber  was  interfaced  from  the 
FSO  link  to  the  media  converter.  From  the  media  converter,  RJ-45  cable  was  interfaced 
to  the  Cisco  2950  Switch. 

On  18  November,  an  850  meter  link  was  established  at  Big  Sur  from  the 
NPS  facility  (fixed  site)  to  the  base  of  a  mountain  where  Nemesis  was  located  (Figure 
13).  Captain  Gilbert  Garcia  and  Captain  David  Joseforsky  set  up  the  fSONA  equipment 
in  order  to  demonstrate  the  ease  of  equipment  setup.  Captains  Garcia  and  Joseforsky 
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were  able  to  set  up  and  establish  the  link  within  60  to  90  minutes.  This  included  aligning 
and  fine-tuning  the  lasers.  Alignment  of  the  lasers  consisted  of  centering  the  distant 
optical  head  in  the  cross  hairs  of  a  riflescope.  Fine-tuning  of  the  lasers  was  conducted  by 
turning  screws  on  the  optical  link  head.  A  voltage  reading,  a  measurement  corresponding 
to  the  received  optical  power  of  the  terminal  of  the  distant  link’s  sensitivity,  was  read  on 
a  voltmeter.  This  reading  was  used  to  fine-tune  the  alignment. 

The  data  collected  from  fSONA’s  FSO  link  was  limited  due  to  network 
issues.  The  initial  plan  was  to  establish  streaming  video  between  two  computers  on 
different  networks,  and  measure  the  throughput.  The  authors  were  unable  to  stream 
video  between  the  LANs  because  of  equipment  limitations.  Next,  video  sharing  was 
attempted  with  less  than  desirable  results.  As  it  turned  out,  only  measured  transmission 
between  the  two  networks  was  during  file  sharing.  Mapping  a  network  drive  and 
connecting  to  the  remote  computer  on  the  different  network  accomplished  this  task.  The 
table  below  gives  the  data  collected  from  fSONA’s  FSO  link  (Table  5). 


17-NOV-03 

Run  No. 

Media 

Size 

Time 

Type 

Throughput 

Packet  Loss  (%) 

1  (Net  Meeting) 

FSO 

7MB 

30  sec 

1:01 

1.2MB 

0% 

2 

FSO 

36MB 

3  min 

1:01 

1.2MB 

0% 

18-NOV-03 

Run  No. 

Media 

Size 

Time 

Type 

Throughput 

Packet  Loss  (%) 

1  (File  Share) 

FSO 

6.5MB 

30  sec 

1:01 

35MB 

2 

FSO 

14/3  5MB 

10s/45s 

2:01 

6.26MB 

files  at  same  time 

Table  5 .  RAW  DATA  FROM  FSONA 

b.  Lightpointe 

Lightpointe  is  a  FSO  company  based  in  San  Diego,  California.  The  team 
was  top-notch  and  was  very  customer-oriented.  The  members  of  this  organization  were 
Jim  McGowen,  Director  of  Sales;  Albert  Borquez,  Senior  Network  Engineer;  and  Steve 
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Hane,  VP  Business.  The  NPS  students  primarily  involved  were  Captain  Gilbert  Garcia, 
Captain  David  Joseforsky,  LT  Albert  Seeman,  and  LT  Jesus  (Manny)  Cordero  (Figure 
16). 


Figure  16.  TEAM  LIGHTPOINT  AND  NPS  STUDENTS 


Testing  with  Lightpointe  was  conducted  on  November  20-21,  2003.  The 
setup  was  straightforward  and  simple.  As  before,  two  LANs  were  established,  one  at  the 
fixed  site  and  the  other  at  the  MRF.  The  distance  between  the  two  sites  was  850  meters. 
The  diagram  below  (Figure  17)  gives  an  overview  of  how  equipment  for  the  experiment 
was  configured. 
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Overall  View  Nov  20-21 


Remote 

(Gil) 

Fixed  Site 


R.V.  Site  (Dave) 


Figure  1 7.  OVERVIEW  DIAGRAM  LIGHTPOINTE 


On  20  November,  the  primary  focus  was  to  see  if  the  outer  switch  would 
be  able  to  handle  both  802.1  lb  and  FSO  simultaneously.  First,  Lightpointe  explained  to 
the  students  how  to  set  up  the  equipment  and  demonstrated  the  ease  of  equipment  setup 
for  the  network. 

Lightpointe  brought  their  FlightStrata-G  Fly  Away  Kit.  The  FlightStrata 
(Figure  18)  has  a  data  rate  of  1.25  Gbps.  It  provides  full  duplex  transmission  at  the 
physical  layer  with  a  flexible  distance  of  1  meter  (can  transmit  any  distance  between  one 
meter  and  4,800  meters).  It  features  automatic  beam  tracking  and  automatic  gain  control. 
It  has  a  Multi-mode  fiber  interface,  but  a  Single-mode  fiber  interface  is  available.  The 
FlightStrata  took  5  minutes  to  acquire  signal  (both  ends  communicating  to  each  other) 
and  about  20  minutes  of  fine-tuning  (optimizing  the  signal  between  the  two  ends). 
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Figure  18.  LIGHTPOINTE  FLIGHTSTRATA  MODEL 

Albert  Borquez,  Lightpointe’s  Senior  Network  Engineer;  LT  Manny 
Cordero,  NPS;  and  Captain  Dwayne  Lancaster  (USMC),  NPS,  configured  the  switches 
and  routers.  Data  was  collected  to  see  if  the  switch  was  able  to  handle  802.1  lb  and  FSO 
simultaneously.  Files  being  sent  were  similar  to  files  that  might  be  used  on  the  battlefield 
between  two  units  (i.e.  data  files  composed  of  Word  documents,  Power  Point  documents. 
Excel  spreadsheets,  PDF  documents,  and  text  documents).  A  6  Megabyte  file  was  sent 
and  recorded  with  a  throughput  of  1  Mbps  using  SolarWinds  (see  annex  for  further 
explanation  of  SolarWinds).  The  following  raw  data  obtained  on  November  20  shows 
the  throughput  results  when  comparing  802.1  lb  and  Lightpointe’s  FSO  (Table  6). 
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Run  No. 

Media 

Size 

Time 

From 

To 

Type 

Throughput 

Packet  Loss  (%) 

1 

FSO 

324M 

r  32” 

1.3 

3.3 

1:01 

34M 

0 

2 

RF 

4M 

V  15” 

1.3 

3.3 

1:01 

500K 

18 

3 

FSO 

147M 

45” 

1.3 

3.3 

1:01 

33M 

0 

4 

FSO 

147M 

41” 

3.3 

1.3 

1:01 

42M 

0 

5 

FSO 

324M 

r 

3.3 

1.3 

1:01 

timed-out 

time-out 

6 

RF 

4M 

34” 

3.3 

1.3 

1:01 

1.3M 

21 

7 

RF 

16K 

5” 

1.3 

3.3 

1:01 

none 

20 

8 

RF 

64K 

3” 

1.3 

3.3 

1:01 

none 

19 

9 

RF 

70K 

2” 

1.3 

3.3 

1:01 

none 

18 

10 

RF 

123K 

4” 

1.3 

3.3 

1:01 

none 

17 

11 

RF 

144K 

3” 

1.3 

3.3 

1:01 

none 

16 

12 

RF 

147K 

1.3 

3.3 

1:01 

15 

Table  6.  RAW  DATA  FROM  LIGHTPOINTE  FSO  AND  RF 


On  21  November,  Captain  Garcia  and  Captain  Joseforsky  established  the 
link  on  their  own.  The  initial  link  setup  took  approximately  5  minutes  and  fine-tuning 
took  an  additional  30  minutes.  This  demonstrated  how  quickly  individuals  with  little 
training  could  deploy  the  system.  The  focus  was  on  FSO  time  latencies.  The  results  of 
the  second  day  of  testing  are  as  follows  (Table  7): 


Run  No. 

Media 

Size 

Time 

From 

To 

Type 

Throughput 

Packet  Loss  (%) 

13 

FSO 

324M 

r  11” 

3.3 

1.3 

1:01 

43M 

0 

14 

FSO 

89M 

19” 

3.3 

1.3 

1:01 

43M 

0 

15 

FSO 

89M 

17” 

1.3 

3.3 

1:01 

46M 

0 

16 

FSO 

32M 

6” 

3.3 

1.3 

1:01 

36M 

0 

17 

FSO 

32M 

7” 

1.3 

3.3 

1:01 

43M 

0 

18 

FSO 

26M 

4” 

3.3 

1.3 

1:01 

31M 

0 

19 

FSO 

26M 

6” 

1.3 

3.3 

1:01 

36M 

0 

20 

FSO 

20M 

5” 

3.3 

1.3 

1:01 

25M 

0 

21 

FSO 

20M 

4” 

1.3 

3.3 

1:01 

14M 

0 

22 

FSO 

4M 

2” 

3.3 

1.3 

1:01 

5.8M 

0 

23 

FSO 

4M 

2” 

1.3 

3.3 

1:01 

5.8M 

0 

24 

FSO 

648M 

2’  20” 

<= 

N:N 

44M 

0 

Table  7.  RAW  DATA  FROM  LIGHTPOINTE  FSO 


The  final  portion  of  the  Lightpointe  test  was  to  physically  cover  different 
portions  of  the  FSO  transceiver  lens  and  annotate  the  results.  The  purpose  of  the  test  was 
to  determine  how  much  of  the  optical  lens  needed  to  be  exposed  in  order  to  effectively 
transfer  data  between  the  two  LANs.  This  test  was  not  conducted  with  fSONA  due  to 
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time  limitations.  While  transferring  a  147  Mb  file  between  two  computers  on  two 
different  LANs,  a  25Mbps  throughput  was  produced  by  covering  one  of  the  four 
transmitting  lasers.  The  entire  optical  head  was  then  covered  until  the  signal  was  lost. 
Once  the  signal  was  lost,  data  stopped  transferring  and  it  took  20  seconds  to  reacquire  the 
signal  after  the  laser  heads  were  uncovered  (the  20  second  interval  is  the  minimum  time 
Cisco  products  need  in  order  to  determine  what  is  currently  connected  in  the  network). 
When  two  laser  heads  were  covered,  a  45  Mbps  throughput  was  produced  across  the 
network.  The  entire  optical  head  was  covered  again  until  the  signal  was  once  again  lost. 
At  that  point,  it  took  20  seconds  to  reacquire  the  signal.  When  three  laser  heads  were 
covered,  a  45  Mbps  throughput  was  produced  across  the  network.  The  signal  was  lost 
when  the  entire  optical  was  covered.  Once  again,  the  signal  stopped  transferring  data, 
and  it  took  20  seconds  to  reacquire  the  signal.  By  walking  in  front  of  the  laser  twice,  the 
signal  was  lost  and  it  took  30  seconds  to  reacquire  the  signal.  By  passing  a  lid  quickly  in 
front  of  the  laser,  the  signal  was  lost.  Finally,  after  passing  a  water  bottle  in  front  of  the 
laser,  the  signal  experienced  a  13  percent  packet  lost.  The  signal  remained  acquired 
throughout  the  water  bottle  test. 

Conclusions  and  recommendations  from  this  experiment  can  be  found  in 
the  Conclusions  and  Recommendations  portion  of  this  thesis. 

c.  802.11b 

The  Naval  Postgraduate  Students  primarily  involved  were  Captain  Gilbert 
Garcia,  Captain  David  Joseforsky,  LT  Albert  Seeman,  and  LT  Jesus  (Manny)  Cordero. 
The  time  period  of  this  testing  experiment  was  November  17-21,  2003. 

The  equipment  used  for  this  testing  was  the  Linksys  Access  Point 

(WAPll).  The  goal  was  to  test  the  throughput  of  802.11b  with  yagi  and  parabolic 

antennas  connecting  two  Linksys  access  points.  The  access  points  were  configured  in 

bridging  mode  for  this  portion  of  the  testing.  On  17  November,  the  802.1  lb  link  was  set 

up  at  550  meters  with  yagi  antennas.  Initial  connectivity  was  established  with  these 

antennas  in  order  to  connect  the  two  networks.  Parabolic  antennas  were  erected  next  to 

establish  connectivity  at  550  meters  connecting  the  two  LANs.  On  18  November,  the 

same  configuration  was  used  at  850  meters  in  order  to  share  files  via  NetMeeting. 

SolarWinds,  a  product  used  to  measure  throughput,  determined  that  NetMeeting  had  a 
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1.27  Mbps  limit  on  the  amount  of  maximum  throughput.  Table  8  below  represents  the 
raw  data  collected  for  this  portion  of  the  experiment. 


17-NOV-03 

Run  No. 

Media 

Size 

Time 

Type 

Throughput 

Packet  Loss  (%) 

1 

Yagi 

20K 

2  sec 

1:01 

2 

Yagi 

164K 

5  sec 

1:01 

3 

Yagi 

7MB 

n/a 

1:01 

526K 

13-27% 

4 

Parabolic 

7MB 

45  sec 

1:01 

1.27MB 

5 

Parabolic 

35MB 

n/a 

1:01 

18-NOV-03 

Run  No. 

Media 

Size 

Time 

Type 

Throughput 

Packet  Loss  (%) 

1  (Net  Meet) 

Parabolic 

35MB 

n/a 

1:01 

736K 

2  (Net  Meet) 

Parabolic 

7MB 

r23" 

1:01 

486K 

3 

Parabolic 

35MB 

6  min 

1:01 

4 

Parabolic 

300MB 

too  long 

1:01 

792K 

5 

Parabolic 

7MB 

1  min 

1:01 

800K 

Table  8.  RAW  DATA  YAGI  AND  PARABOLIC  ANTENNAS 


The  type  of  cable  used  for  the  experiment  was  coaxial  cable  along  with  the 
Comscope  WBC  series  cable  assemblies.  The  3/8  inch  WBC-400  &  WBC-400R  50 
coaxial  cable  assemblies  have  a  maximum  bending  radius  of  two  inches  or  fifty 
millimeters.  Attenuation  at  2500MHz  =  6.8dB/100feet;  3.4dB/50feet;  1.7dB/25feet; 
.17dB/2.5ft. 

Parabolic  and  yagi  antennas  were  used  during  the  testing.  In  order  to 
maximize  the  strength  of  antenna  propagation  pattern,  it  was  important  to  understand  the 
polarization  in  relation  to  the  positioning  of  the  element  with  respect  to  horizontal  versus 
vertical  beam  widths.  When  the  grid  antenna  was  positioned  with  horizontal  polarization, 
the  horizontal  beam  width  was  eight  degrees.  The  respective  elevation  beam  width  was 
three  degrees.  The  parabolic  antenna  tested  was  the  HyperGain  Reflector  Grid  Antenna, 
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HG2424G25,  which  is  seen  in  (Figure  19).  The  specifications  on  the  antenna  are 
provided  below  in  Table  9. 


The  two  polarities  are  illustrated  below: 


Horizontal  Vertical 

Polarity  Polarity 

Figure  19.  PARABOLIC  ANTENNA 


Electrical  Specifications 


Frequency 

2400-2500  MHz 

Gain 

24dBi 

-3  dBi  Beam  Width 

8  degrees 

Cross  Polarization  Rejection 

26  dBi 

Front  to  Back  Ratio 

24  dB 

Sidelobe 

-20dB  Max 

impedance 

50  Ohm 

Max.  Input  Power 

50  Watts 

VSWR 

<  1.5:1  avg. 

Mechanical  Specifications 


Weight 

4.8  lbs.  (2.18  kg) 

Grid  Dimensions 

39.5  in  (1 00  cm)  x  23.5  in  (60  cm) 

Mounting 

2  in.  (50.8  mm)  diameter  mast  max. 

Eievation  Angle 

0  to  +10  degrees 

Operating  Temperature 

-45“  C  to  +85'’  C 

Table  9.  PARABOLIC  SPECS 
25  http://www.hyperlirLktech.coni/web/pdf/hg2424g.pdf 
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The  yagi  antenna  tested  was  a  HyperGain  Radome  Enelosed  Yagi  antenna, 
HG2415Y26  (Figure  20).  The  beam  width  appeared  to  be  30  degrees  regardless  of 
polarization  (Table  10). 


Figure  20.  YAGI  ANTENNA 

Electrical  Speciticatlons  Mechanical  Specifications 


Weight 

1.a  lbs. 

Length 

10'  longth  xS"  diarreter 

Riadome  Material 

UV-inhibit9d  Polymer 

Mounting 

2  a'a"dia.  mast  max. 

Polarization 

Vertical 

Wind  Survival 

>150  MPH 

Frequency 

2400-2500  MHz 

Gain 

14.6  dBi 

-3  dE  Beam  Width 

50  degrees 

Impedance 

50  Ohm 

Max.  Input  Power 

50  Watts 

VSWR 

■c  1.5:1 

Table  10.  YAGI  SPECS 


2.  Beyond  Line-of-Sight  (BLOS) 

No  BLOS  testing  was  eonducted  during  this  experiment.  See  Field  Test  #3 
(Raytheon)  and  Field  Test  #4  (Camp  Roberts). 

3.  Over-the-Horizon  (OTH) 

No  OTH  testing  was  condueted  during  this  experiment.  See  Field  Test  #3 
(Raytheon)  and  Field  Test  #4  (Camp  Roberts). 


B.  FIELD  TEST  #2  (GENERAL  DYNAMICS) 

Students  from  NPS  eondueted  thesis  researeh  for  Marine  Corps  Systems 
Command  on  January  6-9,  2004  with  General  Dynamies  Decision  Systems  (GDDS)  in 
Scottsdale,  AZ.  The  actual  testing  was  done  on  Papago’s  Arizona  National  Guard  base 
three  miles  from  GDDS.  The  following  NPS  students  were  involved  in  the  testing  event: 

26  http://www.hyperlirLktech.com/web/pdf/hg2415y.pdf 


35 


Captain  David  Joseforsky,  Captain  Gil  Garcia,  LT  Manny  Cordero,  LT  A1  Seeman, 
Captain  Dwayne  Lancaster,  and  Captain  Chris  Cox  (USMC). 

The  students.  General  Dynamics  personnel,  and  several  vendors  participated  in 
tactical  communications  testing  for  the  UOC  being  built  by  General  Dynamics.  The 
testing  compared  current  state-of-the-art  commercial  capabilities  in  the  following  areas: 
1)  Wireless  technologies,  2)  Operational  ease  of  use,  3)  Power  and  environmental 
considerations,  and  4)  Communication  bandwidths.  Each  technology  was  evaluated  for 
COC  to  COC  (inter-nodal)  and  COC  to  Antenna  Hill  (intra-nodal)  modes  of  operation. 

The  ultimate  goal  of  this  testing  event  was  to  determine  which  technologies 
increase  throughput  on  the  battlefield  for  the  UOC  program.  The  following  state-of-the- 
art  wireless  technologies  were  tested:  Free  Space  Optics,  802.11b  (over  SecNet-11), 
802.16,  and  Microwave  Link.  Voice  over  Internet  Protocol  (VoIP)  was  implemented  in 
the  local  area  networks  to  test  which  technologies  handled  it  best.  Next,  the  students 
demonstrated  an  OTH  capability  provided  by  combining  four  Iridium  satellite  channels, 
similar  to  the  Expeditionary  Tactical  Communications  System.  Over  this  link,  the 
Iridium  Inverse  Multiplexer  and  Compression  Algorithm,  being  developed  by  Dr.  Glen 
Abousleman  at  Arizona  State  University,  was  utilized.  Finally,  establishing  a  covered 
network  with  General  Dynamics’  In-Line  Network  Encryptor,  KG-235,  was  a  testing 
objective. 

Figure  21  illustrates  the  established  network  at  this  testing  event.  Since  there 
were  two  LANs  in  this  Wide  Area  Network,  the  students  decided  to  configure  three 
separate  subnets.  The  MRF  setup  was  a  192. 168.  Lx  subnet,  the  remote  site  was 
192.168.3.x,  and  the  established  link  between  the  two  networks  was  192.168.2.x.  Thus, 
the  Cisco  3745  routers  on  the  edge  of  the  LAN  were  configured  to  have  the  Ethernet  port 
connected  to  the  link  as  a  192.168.2.1/2  IP  address,  and  the  port  connected  to  the  switch 
within  the  LAN  was  assigned  192.168.1.1  for  the  remote  site  and  192.168.3.1  for  the 
MRF.  Next,  the  Cisco  Call  Manager  Server  and  the  IP  Phones  were  assigned  an  IP 
address  according  to  their  respective  subnet  as  they  came  online.  The  Cisco  3550 
switches  and  DSUs  did  not  have  an  IP  addresses  assigned  to  them. 
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Iridium 

Free  Space  Optic  (FSO) 


Radio  Frequency  Module  jRFM)y3 


IMUX 


IMUX 


'uisco  Router 
.  3745  , 


uisco  Router 
.  3745  , 


Call  Manager 


Cisco  Switch  3550 


Cisco  Switch  3550 


Call  Server/ 
DHCP  Server 


IP  Phone  192.168.1.2/24  192.168.1.3/24 


Call  Manager 


DSU 

Solar  Winds 


Call  Server/ 
DHCP  Server 


192.168.3.2/24 


192.168.3.3/24  192.168.3.4/24  |p  Phone 


Figure  2 1 .  GENERAL  DYNAMICS  TESTING  NETWORK  DIAGRAM 


The  above  figure  eonveys  a  network  without  encryption,  except  when  using 
SecNet-II  over  802.1  Ib.  Since  the  original  goal  was  to  establish  a  covered  network, 
toward  the  end  of  the  week,  General  Dynamics’  In-Line  Network  Encryptor,  KG-235, 
was  inserted  into  the  network  in  place  of  the  Cisco  3745  Routers  to  achieve  a  covered 
network.  Obtaining  this  covered  network  was  unsuccessful  due  to  configuration  issues 
with  the  KG-235.  Thus,  the  entire  testing  event,  except  SecNet-11  testing,  was  done 
without  encryption. 

To  show  the  capabilities  of  each  evaluated  technology  as  far  as  physical  distance, 
the  technologies  are  broken  down  into  three  different  categories:  LOS,  BLOS,  and  OTH. 

1.  Line-of-Sight  (LOS) 
a.  SecNet-11 

SecNet-11  is  a  product  developed  by  Harris  Corporation.  It  is  a  secure, 
NSA  Type  1  and  FIPS- 140  compliant  encryption,  wireless  local  area  network  interface 
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card.  National  Security  Agency’s  certification  of  the  SecNet-1 1  card  does  not  include  the 
system  software/hardware  residing  on  the  host,  or  the  software  contained  on  the  CD 
packaged  with  the  SecNet-11.  The  SecNet-11  card  provides  secure  communication  of 
data  as  well  as  source  and  destination  addresses  without  the  requirement  for  a  hardwired 
network.  The  card  operates  in  the  unlicensed  2.4  GHz  Instrumentation,  Science,  and 
Medical  (ISM)  band  and  will  operate  according  to  the  1 1  Mbps  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE)  802. 1 1  protocol  with  the  additional  processing  time  and 
delay  associated  with  encrypting  the  header  information. 27 

The  SecNet-11  uses  standard  DOD  keying  material.  It  accepts  only  a 
single  red  key  using  the  DS-102  protocol.  The  device  can  be  loaded  with 
UNCLASSIFIED,  CONFIDENTIAL,  or  SECRET  keys.  SecNet-lI  is  not  currently 
approved  for  TOP  SECRET.  A  single  red  key  is  loaded  into  the  card  via  a  Data  Transfer 
Device  (DTD)  (i.e.,  AN/CYZ  10)  using  the  DS-102  protocol.  The  same  key  must  be 
loaded  into  all  local  SecNet-1 1  devices  that  will  intercommunicate.28 

The  SecNet-11  testing  for  this  event  was  done  at  500  meters.  As  seen 
above  in  the  General  Dynamics  Testing  Diagram,  Figure  21,  the  802.1  lb  over  SecNet-1 1 
was  set  up  in  a  point-to-point  link.  SecNet  bridges  were  used  to  transmit  point-to-point. 
Each  bridge  actually  takes  one  of  the  SecNet  cards.  Thus,  the  signal  was  encrypted 
between  both  bridges.  The  rest  of  the  network  was  wired  locally,  so  the  network  was 
relatively  secure.  Next,  the  parabolic  antenna  described  in  field  test  #1  was  used  as  the 
remote  antenna,  and  it  was  connected  to  the  SecNet  card  on  the  bridge  via  an  N-type 
cable.  A  special  connector  was  needed  that  could  screw  into  the  SecNet  card  on  one  end 
and  the  other  end  to  the  N-type  cable.  Furthermore,  the  connection  between  the  bridge 
and  the  Cisco  3745  router  was  a  CAT-5  cable.  Finally,  speed  settings  for  the  ports  on  the 
Cisco  routers  and  switches  needed  to  match  the  speed  of  the  SecNet  bridge.  The  routers 
and  switches  were  set  to  speed  10  vice  speed  100  as  was  done  with  all  the  other 

27  Richard  C.  Shaeffer,  Jr.,  Information  Assurance  Deputy  Director,  NSA,  “Interim  Operational 
Systems  Security  Doctrine  for  the  SecNet-llWireless  Local  Area  Network  (WLAN)  Interface  Card”, 
October  2002. 

28  Richard  C.  Shaeffer,  Jr.,  Information  Assurance  Deputy  Director,  NSA,  “Interim  Operational 
Systems  Security  Doctrine  for  the  SecNet-1 1  Wireless  Local  Area  Network  (WLAN)  Interface  Card”, 
October  2002. 
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technologies  tested  in  order  to  prevent  a  configuration  mismatch  in  the  line  speed.  The 
devices  were  set  for  full  duplex. 

In  order  to  change  the  settings  on  the  bridge,  the  authors  needed  to  connect 
a  computer  to  a  switch  or  hub  via  CAT-5  cable  and  then  from  the  switch  or  hub  to  the 
bridge  via  CAT-5.  Then  they  could  view  the  Graphical  User  Interface  provided  by  the 
software  that  comes  with  the  bridge.  Since  the  bridges  needed  special  settings,  one 
bridge  was  set  as  ‘Master’  and  the  other  bridge  was  set  as  ‘Slave’.  For  this  testing,  the 
‘Master’  was  located  at  the  Mobile  Research  Facility. 

In  the  table  below,  the  column  that  is  titled  ‘Size’  signifies  the  size  of  the 
data  file  that  was  sent  from  one  computer  in  one  network  to  another  computer  in  the 
opposite  network  via  Microsoft  Windows  file  sharing.  The  data  files  consisted  of  Word 
documents.  Power  Point  presentations,  and  PDF  files.  There  was  no  video  or  voice 
utilized  at  the  time  of  this  testing.  The  ‘From’  and  ‘To’  column  show  the  last  digits  of 
the  computer  IP  address  (192.168.x.x).  Table  11  shows  the  data  collected  during  the 
SecNet  testing  at  500  meters. 


Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Loss  (%) 

From 

To 

1 

SECNET  11 

1.5  M 

41" 

946K 

12% 

3.4 

1.2 

2 

SECNET  11 

5  M 

1'03" 

1.06M 

10% 

3.4 

1.2 

3 

SECNET  11 

10  M 

3'29" 

1.13M 

14% 

3.4 

1.2 

4 

SECNET  11 

25  M 

4'05" 

1.19M 

24% 

3.4 

1.2 

5 

SECNET  11 

75  M 

iro7" 

1.13M 

17% 

3.4 

1.2 

6 

SECNET  11 

1.5M 

CNJ 

600K 

9% 

1.2 

3.3 

7 

SECNET  11 

5M 

1'12" 

400K 

14% 

1.2 

3.3 

Table  1 1 .  RAW  DATA  SECNET- 1 1  POINT-TO-POINT 


In  addition  to  the  point-to-point  testing  accomplished  with  SecNet-1 1,  data 
was  collected  on  the  use  of  a  SecNet  access  point  within  a  local  area  network.  In  this 
setup,  an  access  point  with  a  SecNet  card  was  set  up  in  the  Mobile  Research  Facility 
network  with  two  laptops  wirelessly  connected  to  that  access  point.  The  laptops  each  had 
their  own  SecNet  card  inserted.  To  configure  the  laptop  appropriately  with  the  card’s 
software,  the  computer  had  to  be  in  Administrator  mode.  Finally,  the  access  point  was 
wired  into  the  LAN’s  switch  with  CAT-5  cable.  Table  12  below  shows  the  data  obtained. 
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Media 

Size 

Time 

Throughput 

Packet  Loss  (%) 

From 

To 

VOiCE 

SECNET  11 

1.5  M 

6" 

1.2M 

0% 

3.102 

3.103 

NO 

SECNET  11 

5M 

CO 

CM 

2.1M 

0% 

3.102 

3.103 

NO 

SECNET  11 

10  M 

lost 

2.1M 

3.103 

3.102 

NO 

SECNET  11 

10M 

53" 

2.94M 

0% 

3.103 

3.102 

NO 

SECNET  11 

75  M 

r36" 

2.3M 

0% 

3.102 

3.103 

NO 

SECNET  11 

10M 

21" 

4.94M 

0% 

3.102 

3.102 

NO 

SECNET  11 

10M 

30" 

3.93M 

0% 

3.7 

3.102 

NO 

Table  12.  RAW  DATA  SECNET- 1 1  IN  LAN 


The  reason  for  this  testing  was  that  General  Dynamic’s  personnel  were 
interested  in  knowing  how  many  laptops  the  access  point  could  handle.  Since  the 
students  did  not  have  the  ability  to  associate  a  multitude  of  laptops  to  the  access  point, 
they  accomplished  the  goal  by  transferring  large  files  between  computers  in  order  to 
simulate  a  large  volume  of  throughput  in  the  network.  Any  size  file  that  was  above 
75Mb  was  unsuccessful  in  its  transfer  from  one  computer  to  another. 

b.  Radio  Frequency  Module  (RFM) 

GDDS  provided  a  RFM  v3  system  during  two  days  of  the  testing 
evolution,  January  6  and  8,  2004.  Ceragon  Networks  is  the  actual  producer  of  the  RFM 
product.  However,  GDDS  packages  the  product  in  appropriate  cases  along  with  a  Cisco 
2950  switch  for  their  customers.  This  case  along  with  the  microwave  dish  is  field 
expedient  and  hardened  to  withstand  a  rugged  military  environment.  The  antenna  sits  on 
top  of  a  lightweight  telescopic  stand,  which  is  separate  from  the  case.  A  distance  of  9 
kilometers  can  be  reached  with  the  one-foot  antenna,  which  was  used  during  the  testing 
event,  and  13.5  kilometers  with  the  two-foot  antenna.29  RFM  is  a  point-to-point,  line-of- 
sight,  OC-3  capable  (155  Mbps)  microwave  product.  Figure  22  shows  the  RFM  antenna, 
tripod,  and  case. 


29  GDDS,  “Radio  Frequency  Module  (RFM)  v3  Flandout”,  2003. 
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Figure  22.  GDDS  RPM  v3 


Next,  the  frequency  band  that  the  RFM  product  utilizes  can  be  found  in 
Table  13  below.  Whichever  channel  is  chosen,  the  transmitting  and  receiving  frequencies 
are  slightly  separated  in  order  to  avoid  any  interference. 


Channel 

TX  Freq  (MHz) 

RX  Freq  (MHz) 

1 

14515 

14935 

2 

14543 

14963 

3 

14571 

14991 

4 

14599 

15019 

5 

14627 

15047 

6 

14655 

15075 

7 

14683 

15103 

8 

14711 

15131 

Table  1 3 .  RFM  FREQUENCY  BANDS 


The  first  day  of  testing  with  RFM  offered  a  chance  to  become  familiar 
with  the  product  and  work  out  any  problems.  On  the  second  day,  it  was  utilized  with 
MRV’s  Optical  Switch  (OptiSwitch)  that  automatically  switches  over  from  FSO  to  RE  if 
the  FSO  signal  is  lost  or  degraded.  The  RFM  product  was  tested  at  1,000  meters  on  both 
days. 
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During  the  first  day,  some  minor  problems  were  encountered.  Since  the 
RFM  equipment  was  utilizing  the  Cisco  switch  found  within  the  carrying  case,  the  ports 
of  the  switch  were  not  configured  appropriately  to  match  the  Local  Area  Network  routers 
and  switches.  This  equipment  was  configured  for  speed  100  (100  Mbps)  and  full  duplex. 
The  RFM  Cisco  switch  was  set  on  auto-negotiation.  Cisco  products  that  are  not  set  on 
the  same  settings  throughout  the  network  will  not  function  properly,  which  can  cause 
degradation  in  the  networks.  Thus,  initially  the  authors  were  seeing  low  throughput  data 
for  the  RFM  gathered  from  Iperf  (see  appendix  for  explanation  of  Iperf),  which  can  be 
seen  in  Figure  23  below.  Note  that  Iperf  was  sending  a  flood  of  64Kb  size  packets  to  get 
this  throughput  data.  At  this  testing  evolution,  the  authors  were  unable  to  change  the  size 
of  the  packets.  In  the  later  experiments,  the  packet  size  could  be  changed.  The  normal 
throughput  capability  of  the  RFM  system  is  OC-3  (155  Mbps)  but  the  router  and  switch 
ports  could  only  handle  100  Mbps.  In  addition  to  the  low  throughput  data,  the  link  was 
very  unstable  and  constantly  showing  as  signal  lost  in  SolarWinds  network  monitoring 
system  (see  appendix  for  full  explanation)  during  the  times  the  RFM  Cisco  switch  was  set 
at  auto-negotiation. 


Client  connecting  to  192.168.1.2,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.3.4  port  1034  connected  with  192.168.1.2  port  5001 


[  ID]  Interval 
[928]  0.0- 5.0  sec 
[928]  5.0-10.0  sec 
[928]  10.0-15.0  sec 
[928]  15.0-20.0  sec 
[928]  0.0-20.0  sec 


Transfer 
17.1  MBytes 

17.5  MBytes 
15.0  MBytes 
19.0  MBytes 

68.5  MBytes 


Bandwidth 

27.3  Mbits/sec 
28.0  Mbits/sec 
23.9  Mbits/sec 

30.4  Mbits/sec 

27.4  Mbits/sec 


Figure  23 .  RFM  IPERF  DATA  BEFORE  CONFIGURING  SWITCH 


After  getting  the  RFM  Cisco  switch  port  that  was  connected  to  the  existing 
network  set  to  speed  100  and  full  duplex,  the  data  and  link  were  very  consistent  and 
stable.  SolarWinds  showed  the  link  up  throughout  the  rest  of  the  day.  The  Iperf  data 
after  the  proper  configuration  settings  can  be  found  in  Figure  24  below. 
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Client  connecting  to  192.168.1.2,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.3.4  port  1037  connected  with  192.168.1.2  port  5001 


[  ID]  Interval 
[928]  0.0- 5.0  sec 
[928]  5.0-10.0  sec 
[928]  10.0-15.0  sec 
[928]  15.0-20.0  sec 
[928]  0.0-20.0  sec 


Transfer 

32.7  Mbytes 

32.7  MBytes 

32.8  MBytes 
32.5  MBytes 
131  MBytes 


Bandwidth 

52.2  Mbits/sec 

52.3  Mbits/sec 
52.5  Mbits/sec 
52.0  Mbits/sec 

52.3  Mbits/sec 


Figure  24.  RFM  IPERF  DATA  AFTER  CONFIGURING  SWITCH 


On  8  January,  the  RFM  was  utilized  with  MRV’s  OptiSwitch.  Prior  to 
conducting  this  testing,  more  data  was  collected  with  SolarWinds  on  the  actual 
throughput  of  the  RFM  link  while  transferring  data  files,  such  as  Word  documents.  Power 
Point  presentations,  and  PDF  files.  As  it  is  reflected  in  the  data  table  below,  the  link 
would  drop  out  when  attempting  to  transfer  files  bigger  than  300  Mbytes.  However,  it 
was  again  very  consistent  and  stable  for  this  test  for  files  300M  and  smaller.  The  data 
from  SolarWinds  shows  a  much  lower  throughput  than  Iperf  because  the  SolarWinds  data 
was  measuring  how  well  files  transferred  from  computer  to  computer  when  conducting  a 
Microsoft  Windows  file  sharing  session.  In  addition,  the  files  were  very  inconsistent  in 
size  and  type,  while  Iperf  sends  packets  that  are  consistent  in  size  and  type.  See  Table  14 
for  the  SolarWinds  data. 


Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Loss  (%) 

From 

To 

10 

MICROWAVE 

1.5M 

1" 

2.3M 

0% 

3.4 

1.2 

11 

MICROWAVE 

5M 

2" 

7.3M 

0% 

3.4 

1.2 

12 

MICROWAVE 

10M 

2" 

15M 

0% 

3.4 

1.2 

13 

MICROWAVE 

25M 

7" 

36M 

0% 

3.4 

1.2 

14 

MICROWAVE 

75M 

17" 

40M 

0% 

3.4 

1.2 

15 

MICROWAVE 

300M 

r30" 

37M 

0% 

1.2 

3.4 

16 

MICROWAVE 

300M 

1'08" 

43M 

0% 

3.4 

1.2 

17 

MICROWAVE 

600M 

DROP 

1.2 

3.4 

Table  14.  RFM  SOLARWINDS  DATA  ON  8  JANUARY 


In  the  FSO-RF  switchover  test,  the  RFM  Cisco  Switch  was  connected  to 
MRV’s  OptiSwitch  via  a  CAT-5  crossover  cable.  The  reason  for  the  crossover  cable  was 
that  two  like  devices,  switches,  were  connected  to  each  other.  With  both  MRV’s  FSO 
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product  and  the  RFM  connected  to  the  Opti  Switch,  the  transition  from  one  to  the  other 
was  seamless.  In  order  to  facilitate  the  FSO  signal  being  lost,  a  box  was  placed  in  front 
of  the  FSO  link  head.  There  was  no  packet  loss  or  delay  in  the  transfer  of  files  from 
computer  to  computer.  When  the  box  was  taken  away  from  the  link  head,  the  FSO 
product  picked  up  the  transmission  again  without  any  delay  or  noticeable  difference  in 
the  transition.  Again,  SolarWinds  was  used  to  read  the  throughput  data,  and  file  sharing 
between  computers  was  the  method  being  used  to  flood  the  link  with  data.  Table  15 
below  shows  the  data  for  the  FSO-RF  test. 


Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Ijoss  (%) 

From 

To 

19 

FSO 

300M 

rsi" 

24MRF,36MFSO 

0% 

3.4 

1.2 

20 

FSO 

150M 

"50 

41  RF,  42  FSO 

0% 

3.4 

1.2 

21 

FSO 

75M 

"27 

6  RF,  30  FSO 

0% 

1.2 

3.4 

22 

FSO 

300M 

200" 

24  RF,  31  FSO 

0% 

1.2 

3.4 

23 

FSO 

600M 

4'24" 

24  RF,  35  FSO 

0% 

1.2 

3.4 

Table 


5. 


FSO-RF  SWITCHOVER 


c.  fSONA 

After  field  test  #1,  the  authors  were  much  more  familiar  with  fSONA’s 
product,  SONAbeam  155-M.  For  this  testing  evolution,  the  exact  same  setup  for 
fSONA’s  equipment  was  utilized  as  the  previous  testing.  The  SONAbeam  155-M  was 
connected  to  a  media  converter  with  a  single-mode  fiber  cable.  The  media  converter  was 
outfitted  with  a  SC-fiber  connection  with  RJ-45  out  to  the  network’s  router.  Attempts 
were  initially  made  to  connect  fSONA’s  product  directly  from  the  link  heads  to  the 
network  routers  with  the  single-mode  cable.  The  network  routers  were  equipped  with  a 
Gigabit  Network  Interface  Module  to  accept  a  fiber  connection.  This  configuration  of  the 
SONAbeam  155-M  directly  to  the  router  was  unsuccessful.  The  reason  for  this  was  that 
the  single-mode  fiber  interface  on  the  SONAbeam  155-M  was  1310  nanometers.  The 
Gigabit  Network  Interface  Module  only  accepted  850  nanometer  signals  from  the  fiber. 
Next,  the  SONAbeam  155-M  was  set  up  on  the  heavy-duty  stands  that  weighed  a  total  of 
200  pounds  each.  This  provided  the  SONAbeam  155-M  with  a  stable  platform  to  mount 
the  product.  Finally,  fSONA  had  a  separate  Alternating  Current  (AC)  to  Direct  Current 
(DC)  converter.  This  allowed  the  link  head  to  be  plugged  into  the  power  converter  with 
DC  power,  and  then  the  power  converter  had  a  regular  AC  120V  plug  that  went  into  the 
available  generators. 
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fSONA’s  testing  was  conducted  at  1,000  meters  down  an  airfield  runway. 
The  conditions  were  ideal  with  clear  skies  and  sunny  weather.  Scintillation  was  much 
more  prevalent  during  this  testing  event  since  the  link  heads  were  only  six  feet  off  the 
ground  and  the  runway  was  black  pavement.  This  is  significant  because  scintillation  can 
cause  serious  degradation  in  the  laser  being  sent  between  link  heads.  Some  testing  was 
also  done  with  the  SONAbeam  155-M  during  the  nighttime  when  there  was  complete 
darkness,  when  scintillation  is  much  less  of  an  issue. 

Captain  Gilbert  Garcia  and  LT  A1  Seeman  did  the  setup  of  the  SONAbeam 
155-M  equipment.  Pablo  Bandera,  fSONA’s  Product  Manager,  was  available  to  fine- 
tune  the  alignment  of  the  lasers.  A  voltmeter  was  used  to  determine  the  strength  of  the 
signal  between  the  link  heads.  This  established  link  did  not  drop  once  throughout  the  day 
and  proved  to  be  the  most  stable  FSO  link  during  this  event. 

Other  performance  measures  were  taken  during  fSONA’s  allotted  time 
slot  on  the  7  January  2004.  Since  fSONA’s  SONAbeam  155-M  product  has  four 
transmitting  lasers  and  a  large  distinctive  receiving  area,  data  was  gathered  when 
blocking  the  transmitting  lasers  one  at  a  time  starting  with  one,  then  two,  and  finally 
blocking  three  lasers  out  of  the  four.  In  addition,  three  lasers  were  blocked  along  with 
roughly  95%  of  the  receiver  area.  A  picture  of  this  can  be  found  in  Figure  25  below.  The 
lasers  on  the  edges  were  being  blocked  with  cardboard  taped  over  them  and  the  receiver 
area  was  blocked  with  a  pizza  box. 
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Figure  25.  PABLO  BANDERA,  fSONA,  BLOCKS  LASERS  AND  RECEIVER 


The  data  collected  for  the  regular  testing,  blocking  lasers,  and  night  testing 
can  be  found  Table  16  below.  As  can  be  seen  from  the  data,  the  link  was  very  stable  no 
matter  the  size  of  the  files  being  transferred.  During  the  night  testing.  Voice  over  Internet 
Protocol  was  also  implemented.  There  was  one  phone  in  each  respective  network.  Each 
phone  required  about  90  Kbps  of  throughput,  so  it  had  minimal  effect  on  the  performance 
of  the  laser  link.  The  files  being  transferred  were  again  Word  documents.  Power  Point 
presentations,  and  PDF  files.  There  was  no  Iperf  data  gathered  for  fSONA  during  this 
testing  event. 
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Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Loss 

From 

To 

1 

FSO 

1.5  M 

n/a 

2.2M 

0% 

1.2 

3.3 

2 

FSO 

5M 

2" 

6.2M 

0% 

1.2 

3.3 

3 

FSO 

10  M 

3" 

15M 

0% 

1.2 

3.3 

4 

FSO 

25  M 

5" 

34M 

0% 

1.2 

3.3 

5 

FSO 

75  M 

17" 

39M 

0% 

3.4 

1.2 

6 

FSO 

150  M 

39" 

39M 

0% 

3.4 

1.2 

7 

FSO 

300  M 

1'15" 

34M 

0% 

3.4 

1.2 

8 

FSO 

150M 

28" 

54M 

0% 

1.2 

3.3 

9 

FSO 

300M 

57" 

56M 

0% 

1.2 

3.3 

10 

FSO 

600M 

2'58" 

47M 

0% 

1.2 

3.4 

11 

FSO 

1.2G 

5'20" 

54M 

0% 

1.2 

3.4 

1  lasers  blocked 

12 

FSO 

300M 

ri3" 

44M 

0% 

1.2 

3.4 

2  lasers  blocked 

13 

FSO 

300M 

1'15" 

50M 

0% 

1.2 

3.4 

3  lasers  blocked 

14 

FSO 

300M 

ri5" 

50M 

0% 

12 

3.4 

lasers/receiver  blocked 

NO  DAI 

~A  GATHERED, 

LINK  PI 

3  NOT  DROP 

10 

FSO 

1.5  M 

N/A 

11 

FSO 

5M 

2" 

7M 

0% 

1.2 

3.4 

12 

FSO 

10  M 

3" 

15M 

0% 

1.2 

3.4 

13 

FSO 

25  M 

5" 

37M 

0% 

1.2 

3.4 

14 

FSO 

75  M 

20" 

31M 

0% 

3.4 

1.2 

15 

FSO 

300M 

1'20" 

42M 

0% 

1.2 

3.4 

16 

FSO 

300  M 

r35" 

30M 

0% 

3.4 

1.2 

17 

FSO 

600  M 

3' 15" 

44M 

0% 

1.2 

3.4 

18 

FSO 

1.2  GIG 

6'05" 

46M 

0% 

1.2 

3.4 

Table  16. 


FSONA  DATA  7  JAb 


UAY 


d.  MRV 

Tim  Kcehowski,  Director  of  Federal  Sales,  Levon  Fayson,  Technical 
Support  Engineering  Manager,  and  Isaac  Kim,  Director  of  FSO,  from  MRV 
Communications  supported  this  testing  event.  Mr.  Fayson  was  instrumental  in  setting  up 
the  Terescope  3000  OC-3  link  heads.  The  distance  between  both  sites  was  1,000  meters 
over  a  black  pavement  runway,  and  the  weather  was  ideal  with  clear  skies  and  a 
temperature  in  the  70-degree  range. 

The  Terescope  3000  OC-3  specifications  state  that  it  can  reach  out  to  4 
kilometers  with  a  3  dB  loss  per  one  kilometer,  which  would  equate  to  light  haze,  and  still 
provide  99.999%  reliability.30 

MRV  also  brought  along  with  them  their  OptiSwitch  that  automatically 
switches  over  from  FSO  to  RF  when  the  FSO  link  is  lost.  The  MRV  TereScope  product 
supports  a  patent  optional  software  feature  called  “Terescope  Fusion”.  This  feature 

30  Isaac  Kim,  “Terescope  Free  Space  Optics  Overview  Brief’,  2003. 
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provides  auto  switch  over  from  the  TereScope  product  to  any  back  up  RF  system.  The 
software  in  the  Terescope  communicates  with  the  MRV  manufactured  OptiSwitch 
product  to  provide  switching  between  the  FSO  and  backup  RF  system.  The  OptiSwitch 
also  has  unique  software  to  communicate  with  the  Terescope.  The  RFM  product  was 
used  as  the  backup  RF  system  during  this  testing  event.  Figure  26  below  demonstrates 
MRV’s  OptiSwitch  used  during  the  testing  event. 


Figure  26.  MRV  OPTISWITCH  200 

From  the  Terescope  3000,  there  was  a  multi-mode  fiber  cable  that  ran  to 
the  media  converter  that  MRV  brought  with  them.  The  media  converter  had  an  RJ-45 
connection  that  went  from  the  converter  to  the  network’s  3745  router.  Next,  there  was  a 
AC  to  DC  converter,  separate  from  the  link  head,  which  allowed  the  DC  powered  link 
head  to  be  plugged  into  the  available  AC  120V  power  source  on  the  generators. 

The  Terescope  3000  alignment  process  was  done  via  a  camera  located 
within  the  Terescope.  This  camera  is  capable  of  seeing  the  laser  light  from  the  other  link 
head.  One  can  view  what  the  camera  is  seeing  on  a  display  that  is  separate  from  the 
actual  link  head.  The  video  alignment  software  is  built  into  the  TereScope  product,  and  it 
can  be  remotely  viewed  by  extending  the  video  back  to  the  user  in  the  Operations  Center. 
Once  the  camera  sees  the  laser  light  from  the  other  link  head,  one  can  manually  move  the 
link  head  to  get  the  laser  light  in  the  center  of  the  cross  hairs  on  the  video  display.  The 
alignment  process  was  relatively  simple  once  viewed  on  the  display  screen.  See  Figure 
27  below  to  view  MRV’s  Terescope  3000  and  the  display  screen  for  the  alignment.  The 
camera  feature  can  also  be  viewed  on  other  sources  such  as  laptops  and  palm  pilots  by 
taking  either  a  CAT  5  cable  or  fiber  connection  out  of  the  Scope  to  the  network 
equipment.  In  addition  to  the  patent  MRV  video  alignment,  MRV  is  adding  tracking  and 
auto  alignment  into  their  units. 
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Figure  27.  MRV  TERESCOPE  3000  W/  ALIGNMENT  DISPLAY 


Throughput  data  was  collected  on  the  Terescope  3000  via  file  sharing  on 
Microsoft  Windows  and  packet  flooding  on  Iperf.  The  data  collected  was  inconsistent, 
with  considerable  packet  loss  when  transferring  large  flies.  In  addition,  no  flies  larger 
that  300  Mbytes  could  be  transferred  between  computers  on  the  different  networks. 
Table  17  below  shows  the  file  sharing  data  collected  utilizing  SolarWinds  as  the 
measuring  tool. 
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Mil  III! 

Media 

Size 

Time 

Throughput 

Packet  Loss 

From 

To 

FSO 

1.5  M 

1" 

2.2M 

0% 

3.4 

1.2 

2 

FSO 

5M 

2" 

7.3M 

0% 

3.4 

1.2 

3 

FSO 

10M 

5" 

9M 

0% 

1.2 

3.3 

4 

FSO 

25  M 

7" 

27M 

0% 

3.4 

1.2 

5 

FSO 

75  M 

34" 

25M 

0% 

1.2 

3.3 

6 

FSO 

150  M 

drop 

7 

FSO 

300  M 

r54" 

25M 

15% 

1.2 

3.3 

8 

FSO 

600  M 

1.2 

3.3 

9 

FSO 

1.2  GIG 

10 

FSO 

1.5  M 

1" 

2.3M 

7% 

3.4 

1.2 

11 

FSO 

5M 

2" 

7.3M 

0% 

1.2 

3.3 

12 

FSO 

10M 

7" 

11M 

0% 

1.2 

3.3 

13 

FSO 

25  M 

20" 

10M 

0% 

1.2 

3.3 

14 

FSO 

75  M 

31" 

23M 

20% 

3.4 

1.2 

15 

FSO 

150  M 

drop 

16 

FSO 

300  M 

4'00" 

16M 

0-4% 

1.2 

3.3 

17 

FSO 

600  M 

18 

FSO 

1.2  GIG 

Tab 

lel7.  MRV  DATA  8  JA; 

NUARY 

The  throughput  readings  were  low  for  a  system  that  is  capable  of  OC-3 
rates  (limited  to  100  Mbps  due  to  the  network  ports).  After  getting  these  readings, 
considerable  time  was  spent  on  troubleshooting  the  problem.  It  was  believed  that  the 
settings  on  the  media  converter  were  incorrect,  so  calls  were  made  back  to  MRV’s  office. 
After  establishing  what  was  believed  to  be  the  right  settings,  the  authors  set  up  laptops  off 
of  the  link  heads  through  the  media  converters  on  both  sides  and  used  Iperf  to  gather  the 
throughput  data.  This  data  can  be  found  in  Figure  28  below. 


Client  connecting  to  192.168.64.221,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.64.220  port  1083  connected  with  192.168.64.221  port  5001 


[  ID]  Interval 
[928]  0.0-  5.0  sec 
[928]  5.0-10.0  sec 
[928]  10.0-15.0  sec 
[928]  15.0-20.0  sec 
[928]  0.0-20.0  sec 


Transfer 
33.0  MBytes 

32.9  MBytes 

32.9  MBytes 

32.9  MBytes 
132  MBytes 


Bandwidth 

52.7  Mbits/sec 

52.6  Mbits/sec 

52.7  Mbits/sec 

52.6  Mbits/sec 

52.7  Mbits/sec 


Figure  28.  MRV  IPERF  DATA  8  JANUARY 
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While  this  data  shows  a  big  improvement  from  the  previous  experiment 
with  SolarWinds,  it  was  still  low  for  a  connection  between  computers.  The  established 
networks  were  not  involved,  which  usually  slows  the  throughput  down  at  least  10%. 
When  MRV  went  back  to  their  labs  after  the  testing  event,  they  determined  that  the  media 
converters  were  not  set  properly,  as  they  attained  throughput  near  100  Mbps  in  the  labs. 

The  FSO-RF  switchover  with  the  OptiSwitch  was  a  huge  success.  Both 
the  Terescope  3000  and  the  RFM  were  connected  to  the  OptiSwitch  with  CAT-5  cable; 
and  the  FSO  link  was  going  through  the  media  converter.  The  Terescope  Fusion  in 
conjunction  with  the  OptiSwitch  was  set  to  have  the  FSO  link  as  the  priority  link,  so  that 
was  the  link  that  would  be  used  unless  the  FSO  link  was  lost.  This  type  of  setup  proves 
beneficial  for  situations  when  the  weather  is  unpredictable.  If  fog  rolls  in  and  the  link  is 
at  1,000  meters,  then  the  OptiSwitch  will  eventually  start  to  sense  the  power  level  of  the 
link  being  insufficient  to  get  to  the  other  side.  At  this  point,  the  RF  link  would  take  over. 
For  this  testing  event,  since  the  weather  was  ideal,  a  box  was  placed  in  front  of  the 
Terescope  to  drop  the  FSO  link  and  demonstrate  how  the  RF  picks  up  the  connectivity. 
After  a  short  while,  the  box  was  taken  away  from  the  FSO  link  and  the  Terescope  came 
back  up  as  the  priority  link.  The  data  collected  during  this  testing  was  from  SolarWinds 
and  it  can  be  found  in  Table  18  below. 


Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Loss  (%) 

From 

To 

19 

FSO 

300M 

r3T 

24M  RF,  36M  FSO 

0% 

3.4 

1.2 

20 

FSO 

150M 

"50 

41  RF,  42  FSO 

0% 

3.4 

1.2 

21 

FSO 

75M 

"27 

6  RF,  30  FSO 

0% 

1.2 

3.4 

22 

FSO 

300M 

2'00" 

24  RF,  31  FSO 

0% 

1.2 

3.4 

23 

FSO 

600M 

4'24" 

24  RF,  35  FSO 

0% 

1.2 

3.4 

Table  18.  MRV  AND  RFM  W/  MRV’S  OPTISWITCH 


Large  file  transfers  were  used  to  extend  the  time  it  took  to  accomplish  the 
transfer.  This  assisted  the  authors  in  viewing  the  capability  of  the  OptiSwitch  and  for 
them  to  see  if  the  transfer  was  interrupted  or  if  any  packet  loss  occurred.  Neither  of  these 
situations  took  place. 

e.  Lightpointe 

Lightpointe’s  team  consisted  of  Jim  McGowan,  Sales  Director,  and  Albert 
Borquez,  Network  Engineer.  They  brought  their  FlightStrata  Gigabit  Fly  Away  Package 
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with  them,  which  consisted  of  one  ruggedized  travel  case  per  link  head  and  accessories. 
This  whole  case  weighs  about  70  pounds  and  is  easily  rolled  around  via  a  handle  and 
wheels  attached  to  the  case.  The  FlightStrata  transmits  four  redundant  beams  of  light  that 
overlap  and  adjust  via  Multi-Beam  Array  Tracking  (MEAT)  technology.  The  system 
also  has  an  Automatic  Power  Control  feature  that  allows  the  link  head  to  automatically 
adjust  its  power  output  based  on  the  situation  with  weather  or  distance.3i  Finally,  the  link 
head  sits  on  top  of  a  lightweight,  three-foot,  telescopic  tripod  that  fits  into  the  traveling 
case. 

The  setup  was  fast  and  simple.  The  FlightStrata  proved  to  be  the  easiest  to 
set  up  out  of  all  FSO  products.  After  setting  up  the  stand,  the  link  head  was  attached  to 
the  top  with  four  screws.  There  was  also  a  separate  box  for  the  AC  to  DC  power 
conversion  to  facilitate  an  AC  120V  plug-in  to  the  generators.  Furthermore,  the 
alignment  was  simple  but  not  the  most  advanced  feature.  The  scope  to  find  the  other  end 
was  built-in  to  the  link  head.  After  getting  close  to  the  alignment,  the  Light  Emitting 
Diode  (LED)  indicator  on  the  back  of  the  link  head  was  utilized  as  the  link  head  was 
manually  adjusted  to  try  and  obtain  the  strongest  signal.  This  was  signified  by  the 
amount  of  LED  bars  that  lit  up.  It  was  best  to  do  this  one  side  at  a  time  and  to  have  voice 
contact  with  the  other  side  in  order  to  get  feedback  from  them  as  to  what  their  LED  bars 
were  indicating. 

During  this  testing  evolution,  Lightpointe  utilized  multi-mode  cable  from 
their  FlightStrata  directly  to  the  network’s  Gigabit  Interace  Modules  on  the  Cisco  3745 
routers.  This  allowed  them  to  avoid  using  the  media  converters.  Lightpointe  was  the 
only  FSO  company  able  to  connect  their  link  head  directly  to  the  router  with  fiber 
throughout  the  week.  The  data  results  were  very  stable  and  the  throughput  was  greater 
than  other  companies  mostly  due  to  the  direct  fiber  connection  to  the  router  from  the 
FlightStrata.  Table  19  below  shows  the  results  obtained  from  SolarWinds  throughout  the 
day  while  doing  file  transfers,  file  transfers  and  VoIP,  and  file  transfers  and  VoIP  while 
blocking  lasers. 


31  http://www.lightpointe.com/index.cftn/fuseaction/products.flightstrata  (April  2004). 
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Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Loss 

From 

To 

1 

FSO 

1.5  M 

1" 

2.3M 

0% 

3.4 

1.2 

2 

FSO 

5  M 

1" 

7.3M 

0% 

3.4 

1.2 

3 

FSO 

10  M 

1" 

15M 

0% 

1.2 

3.3 

4 

FSO 

25  M 

5" 

31M 

0% 

3.4 

1.2 

5 

FSO 

75  M 

15" 

53M 

0% 

1.2 

3.3 

6 

FSO 

150  M 

27" 

53M 

0% 

3.4 

1.2 

7 

FSO 

300  M 

1'03" 

56M 

0% 

1.2 

3.3 

8 

FSO 

600  M 

NOT  ATTEMPTED 

9 

FSO 

1.2  GIG 

5'00'’  1 

1  50M  1 

1  0% 

3.4 

1.2 

1  LASER  BLOCKED 

2  LASERS  BLOCKED 

3  LASERS  BLOCKED 

10 

FSO 

1.5  M 

1" 

2.3M 

0% 

3.4 

1.2 

11 

FSO 

5M 

1" 

7.4M 

0% 

3.4 

1.2 

12 

FSO 

10  M 

r 

15M 

0% 

3.4 

1.2 

13 

FSO 

25  M 

4' 

15M 

0% 

3.4 

1.2 

14 

FSO 

75  M 

15" 

47M 

0% 

3.4 

1.2 

15 

FSO 

150  M 

32" 

54M 

0% 

1.2 

3.4 

16 

FSO 

300  M 

54" 

48M 

0% 

3.4 

1.2 

17 

FSO 

600  M 

2'20" 

53M 

0% 

3.4 

1.2 

18 

FSO 

1.2  GIG 

5'02" 

55M 

0% 

3.4 

1.2 

19 

FSO 

300M 

56" 

61M 

0% 

3.4 

1.2 

20 

FSO 

300M 

52" 

54M 

0% 

3.4 

1.2 

21 

FSO 

300M 

49" 

55M 

0% 

3.4 

1.2 

Table  ] 

[9.  LIGHTPOIl 

^TE  DAI 

W  9  JAb 

fUARY 

As  one  can  see,  the  link  was  able  to  handle  any  size  file  transfer  without 
packet  loss,  and  a  subset  of  the  lasers  being  blocked  had  no  negative  effect  on  the  link. 
Below  in  Figure  29  are  the  results  from  Iperf  when  64  Kbyte  size  packets  were  flooding 
the  link. 


Client  connecting  to  192.168.1.2,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.3.4  port  1 148  connected  with  192.168.1.2  port  5001 


[  ID]  Interval 
[928]  0.0-  5.0  sec 
[928]  5.0-10.0  sec 
[928]  10.0-15.0  sec 
[928]  15.0-20.0  sec 
[928]  0.0-20.0  sec 


Transfer 

50.1  MBytes 
50.0  MBytes 

50.4  MBytes 

50.4  MBytes 
201  MBytes 


Bandwidth 

80.1  Mbits/sec 

80.1  Mbits/sec 
80.7  Mbits/sec 

80.5  Mbits/sec 
80.3  Mbits/sec 


Figure  29.  LIGHTPOINTE  IPERF  DATA 
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Lightpointe’s  Iperf  data  was  the  strongest  throughout  the  entire  week.  The 
link  did  tend  to  drop  a  couple  of  times  for  a  few  seconds  possibly  due  to  cars  driving 
down  the  runway  in  the  line  of  the  laser  link,  dust  being  kicked  up  by  the  cars,  or 
scintillation  from  the  sun  hitting  the  black  runway.  In  addition,  the  sporadic  link  drop 
could  have  been  due  to  Lightpointe’s  tripod  stand  being  only  3  feet  off  the  ground,  the 
lowest  out  of  all  the  companies. 

f.  Ensemble 

Ensemble  Communications  supported  this  evolution  with  Jeff  Nightingale, 
Sales  Director,  Corey  Koberg,  Engineer,  and  Jerry  Shirey,  Field  Technician.  They 
brought  equipment  that  utilizes  802.16  technology.  802.16  is  made  for  Wide  Area 
Networks  (WAN),  much  like  802.1  lx  is  utilized  in  Local  Area  Networks.  In  the 
commercial  sector,  802.16  is  used  for  backhaul  broadband  wireless  connectivity  for  many 
service  providers.  IEEE  has  already  developed  standards  for  802.16a  (2-11  GHz)  and 
802.16c  (10-66  GHz).  The  reason  this  technology  is  made  for  Wide  Area  Networks 
(WAN)  is  because  of  its  point-to-multipoint  features.  The  equipment  comes  in  the 
following  parts:  hub  station,  multiplexer,  and  antenna.  At  the  hub  station,  Ensemble  can 
use  60,  90,  and  180-degree  antennas  to  provide  360-degree  coverage  to  the  remote 
stations.  The  remote  stations  have  the  multiplexer  with  their  own  appropriate  type  of 
sector  antenna.  Ensemble’s  products  operate  on  the  Asynchronous  Transfer  Mode 
(ATM)  protocol.32  A  new  product  line  is  being  developed  to  support  Internet  Protocol. 

Since  Ensemble’s  system  was  ATM  based,  the  authors  attained  a  Single 
port  ATM  OC-3  Single-mode  Intermediate  Reach  NM  card  for  the  Mobile  Research 
Facility’s  3745  router.  The  16200  Hub  Station  was  connected  to  the  port  on  the  card  with 
a  single-mode  fiber  cable.  The  320  Multiplexer  was  on  the  other  end,  connected  to  the 
3745  router  with  CAT-5  cable.  A  Fiberless  282  Series  Outdoor  Mounted  Unit  (ODU) 
was  utilized  for  the  antenna.  It  operates  in  the  27.50  to  28.55  GHz  range.  Other  ODU’s 
can  be  utilized  which  can  operate  in  the  24  to  40  GHz  range.33  A  special  frequency 
request  was  sent  to  the  Navy/Marine  Corps  Spectrum  Center  to  get  temporary 

32  http://www.ensemble.cotn/product/index.asp  (April  2004). 

33  Ensemble  Communications,  “Fiberless  Integrated  Antenna  and  Radio  Outdoor  Unit”,  December 
2003. 
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authorization  to  utilize  the  frequency  band  in  order  to  operate  the  282  Series  ODU.  As 
mentioned  earlier,  the  antennas  mostly  function  in  a  point-to-multipoint  environment. 
However,  in  this  testing  only  point-to-point  was  attempted  utilizing  the  90-degree  sector 
antennas  at  both  sites. 

To  further  explain  Ensemble’s  product  capabilities,  the  ODUs 
communicate  between  the  hub  station  and  multiplexer  sites  using  the  company’s 
revolutionary,  patented  Adaptix  broadband  airlink  technology  to  maximize  system 
capacity  and  efficiency  in  real  time.  Physical  layer  Adaptix  features  include  both 
Adaptive  Time  Division  Duplexing  (TDD)  and  Adaptive  Modulation.  Adaptive  TDD 
uses  a  single  RF  channel  for  both  upstream  and  downstream  communications  and  permits 
the  system  to  adapt  in  real-time  to  the  exact  asymmetry  of  subscriber  traffic  burst  by 
burst.  Adaptive  TDD  also  fits  easily  into  the  many  different  kinds  of  spectrum 
allocations  worldwide  including  block,  paired,  and  split  band  frequency  licenses.  The 
ODU’s  excellent  phase  noise  characteristics  enable  the  system  to  support  not  only  QPSK 
and  16QAM,  but  also  64QAM  operation  burst  by  burst.34 

Ensemble’s  link  was  set  up  to  attain  a  maximum  throughput  of  66  Mbps 
with  that  being  split  between  the  two-way  traffic.  Thus,  if  both  sites  were  sending  data  at 
the  same  time,  then  each  flow  of  traffic  would  be  allotted  33  Mbps  of  throughput.  Next, 
the  setup  of  the  equipment  required  detailed  configuration  of  the  router  at  the  hub 
station’s  site.  This  ended  up  taking  approximately  six  hours  of  work  with  several 
individuals  working  on  the  configuration.  The  ATM  configuration  proved  to  be  much 
more  complex  than  Internet  Protocol,  which  was  used  by  all  the  other  companies. 

Data  was  collected  in  SolarWinds  for  the  throughput  capabilities  of 
Ensemble’s  equipment.  Again,  data  file  transfers  were  conducted  between  laptops  on  the 
two  networks,  and  VoIP  was  being  utilized  during  these  transfers.  See  Table  20  below 
for  this  data. 


34  Ensemble  Communications,  “Fiberless  Integrated  Antenna  and  Radio  Outdoor  Unit”,  December 
2003. 


55 


Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Loss  (%) 

From 

To 

1 

802.16 

1.5  M 

1" 

2.3M 

0% 

3.4 

1.2 

2 

802.16 

5  M 

13" 

4.42M 

0% 

1.2 

3.4 

3 

802.16 

10  M 

25" 

5.4M 

0% 

1.2 

3.4 

4 

802.16 

25  M 

50" 

5.0M 

0% 

1.2 

3.4 

5 

802.16 

75  M 

1'07" 

12M 

9% 

3.4 

1.2 

6 

802.16 

150  M 

5'15" 

5M 

0% 

1.2 

3.4 

7 

802.16 

25M 

CM 

11M 

0% 

3.4 

1.2 

8 

802.16 

75M 

roo" 

11M 

0% 

3.4 

1.2 

9 

802.16 

150M 

3'05" 

11M 

0% 

3.4 

1.2 

Tab 


e  20. 


ENSEMBLE  802.16  DATA  8  JANUARY 


After  analyzing  the  data,  it  was  evident  that  the  yielded  throughput  data 
was  low  compared  to  the  other  technologies.  However,  since  the  channel  capacity  was 
about  33  Mbps  one  way,  this  data  compares  similarly  with  the  other  companies  observed 
throughput  as  a  proportion  of  maximum  channel  capacity.  The  other  companies  were 
attaining  40-60%  capability  of  the  link  while  connected  to  the  LANs  and  also  conducting 
Microsoft  Windows  fde  sharing. 


Below  in  Figure  30  is  the  throughput  data  from  Iperf  that  was  obtained  by 


flooding  Ensemble’s  link  with  64  Kbyte  size  packets. 


Client  connecting  to  192.168.1.2,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.3.4  port  1033  connected  with  192.168.1.2  port  5001 


[  ID]  Interval 
[928]  0.0- 5.0  sec 
[928]  5.0-10.0  sec 
[928]  10.0-15.0  sec 
[928]  15.0-20.0  sec 


Transfer 

6.3  MBytes 

6.4  MBytes 
6.4  MBytes 
6.4  MBytes 


Bandwidth 

10.1  Mbits/sec 

10.2  Mbits/sec 

10.2  Mbits/sec 

10.3  Mbits/sec 


[928]  0.0-20.0  sec  25.5  MB34es  10.2  Mbits/sec 


Figure  30.  ENSEMBLE  IPERF  DATA  8  JANUARY 


Note:  Ensemble  Communieations  deeided  to  shut  down  the  eompany  in 

April  2004. 

g.  Digital  Switch  Unit  (DSU) 

One  of  the  main  reasons  for  eondueting  an  experiment  in  Seottsdale,  AZ 
was  to  work  with  the  UOC  team  and  their  equipment.  The  Digital  Switeh  Unit  (DSU)  is 
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the  heart  of  how  the  UOC  will  operate  in  the  future.  This  system  provides  the  user 
access,  from  a  laptop  or  an  operator  access  unit,  to  all  available  voice  circuits  (radio  and 
telephone).  The  connectivity  is  obtained  by  connecting  the  laptop  to  one  of  the 
Jackboxes  available  at  each  operator  station.  Control  of  the  communication  devices  is 
through  a  Graphical  User  Interface  (GUI)  software  application  resident  on  the  laptop. 
This  provides  the  button  to  access  the  Public  Switched  Telephone  System  (PSTN),  Plain 
Old  Telephone  System  (POTS)  and  any  radios  connected  to  the  Communications  net.35 
A  VoIP  intercom  system  will  also  be  available  to  use  through  the  DSU.  From  the  laptop, 
the  user  has  the  ability  to  call  anyone  in  the  LAN  through  the  GUI.  Additionally,  this 
arrangement  can  be  used  in  the  COC  to  Antenna  Hill  scenario. 

During  this  testing  evolution,  the  UOC  team  first  brought  out  their 
Engineering  Development  Model  DSUs  to  set  up  within  the  respective  LANs.  After 
some  trouble  with  the  configuration  the  first  few  days,  a  decision  was  made  to  use  the 
Low  Rate  Initial  Production  DSUs.  On  Friday,  January  9,  the  DSUs  were  connected  to 
the  LANs  with  success. 

The  setup  of  the  UOC  equipment  at  the  Mobile  Research  Facility  was 
relatively  straightforward.  The  General  Dynamics’  Panasonic  Toughbooks  were 
connected  to  the  LAN  Cisco  3550  switch  with  CAT-5  cable,  and  the  DSU  was  also 
connected  to  the  LAN  Cisco  3550  switch  with  CAT-5  cable.  This  was  the  same  setup  for 
the  other  LAN.  The  link  between  the  two  LANs  was  Lightpointe’s  FSO  product, 
FlightStrata-G.  On  the  Toughbooks,  there  was  a  GUI  available  to  make  VoIP  calls 
within  either  LAN.  Utilizing  the  GUI  was  a  success  while  communicating  across  the 
network.  The  quality  of  the  voice  transmissions  was  excellent  and  there  seemed  to  be  no 
delay. 

The  disadvantage  of  this  setup  was  that  the  two  LANs  needed  to  be  on  the 
same  subnet  in  order  for  the  DSUs  to  work  effectively.  This  would  be  sufficient  for  a 
COC  to  Antenna  Hill  scenario,  but  if  attempting  to  go  from  COC  to  COC  this  would  not 
be  a  realistic  option.  Further  research  needs  to  be  done  into  the  Internet  Protocol 
addressing  scheme  with  the  DSUs. 

35  General  Dynamics  Decision  Systems,  “UOC  Summary  Brief’,  2003. 
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h.  Voice  Over  Internet  Protocol  (VoIP) 

The  authors  were  able  to  expand  upon  their  thesis  research  objectives  after 
conferring  with  other  students  at  the  Naval  Postgraduate  School.  This  research  team 
recognized  the  various  potential  benefits  of  bringing  in  another  student  that  was  doing 
VoIP  thesis  research.  LT  Manny  Cordero  was  able  to  easily  merge  his  thesis  objectives 
into  the  author’s  testing  events.  Since  the  authors  were  already  planning  on  setting  up 
two  LANs  to  test  the  different  transformational  technologies,  LT  Cordero  implemented 
his  equipment  right  into  the  network.  Consequently,  LT  Cordero  was  able  to  see  how 
VoIP  reacted  to  the  different  types  of  throughput  capabilities.  The  authors  were  able  to 
attain  a  Cisco  Call  Manager  Server,  MCS-7825H-2.2  EVVl  model,  and  two  7960G  VoIP 
telephones  from  Cisco  for  the  VoIP  testing.  The  7960G  phone  can  be  seen  in  Figure  31 
below. 


Figure  3 1 .  CISCO  VOIP  7960G  PHONE 


Once  at  GDDS,  Don  Lesmeister,  the  coordinator  of  the  testing  event  at 
General  Dynamics,  provided  additional  Cisco  7940G  and  7960G  telephones  due  to  the 
two  telephones  originally  attained  having  different  protocol  loads.  Tony  Cordaro  from 
Ocean  Systems  Engineering  Corporation  (OSEC)  was  also  instrumental  in  providing 
support  to  LT  Cordero  in  getting  the  VoIP  functional.  Mr.  Cordaro  normally  assists  the 
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UOC  team  with  their  network  setup,  so  Don  Lesmeister  invited  him  to  Scottsdale  to 
observe  this  testing  evolution. 


As  mentioned  earlier,  a  mixture  of  Cisco  7940G  and  7960G  IP  telephones 
were  used  to  provide  voice  service  throughout  the  network.  The  phones  took  a  simple 
CAT-5  cable  connection,  while  the  other  end  was  connected  to  the  LAN  Cisco  3550 
switch.  The  Call  Manager  server  was  always  located  in  the  MRF.  The  phones 
throughout  the  two  LANs  first  talked  to  the  server  before  making  a  call  to  another  phone 
within  the  network.  The  server  was  connected  to  the  MRF  Cisco  3550  switch  via  CAT-5 
cable.  Each  phone  and  server  was  assigned  its  own  unique  IP  address. 

Once  the  phones  established  connectivity,  the  authors  were  able  to 
measure  the  throughput  of  a  VoIP  phone  call.  SolarWinds  was  able  to  monitor  the  LAN 
routers,  so  it  measured  throughput  during  a  phone  call.  A  call  between  two  phones  took 
up  about  90  Kbps  of  throughput.  During  this  testing  event,  the  students  were  unable  to 
establish  more  than  one  phone  within  the  LANs  due  to  equipment  limitations.  With  the 
technologies  being  tested,  the  available  throughput  far  exceeded  the  requirement  of  the 
phone  call  so  the  Quality  of  Service  was  excellent.  The  VoIP  protocol  employed  was 
Cisco’s  Call  Manager  Skinny  Client  Control  Protocol  (SCCP).  SCCP  is  a  Cisco 
proprietary  protocol  used  between  Cisco  Call  Manager  and  Cisco  VoIP  phones  (7940G 
and  7960G  IP  phones).  Other  vendors  also  support  this  protocol.  The  Cisco  IP  Phones 
7960G  and  7940G  are  also  capable  of  supporting  other  protocols  such  as  Session  Initiated 
Protocol  (SIP)  and  Media  Gateway  Control  Protocol  (MGCP). 

L  Crypto  (KG-235  In-Line  Network  Encryptor  (INE)) 

GDDS  provided  two  KG-235  Sectera  In-Line  Network  Encryptors  (INE) 
and  a  trained  operator  from  the  company,  Russ  Harris,  to  set  them  up.  GDDS  is  actually 
the  manufacturer  of  this  product  as  well.  The  intent  of  using  these  devices  was  to  secure 
the  link  between  the  two  LANs  and  to  measure  if  there  was  any  noticeable  difference  in 
the  throughput  with  the  encryption  applied. 

The  Sectera  INE  is  specifically  designed  to  support  IP/Ethemet  operating 
over  standard  commercial  networks  that  require  U.S.  Government  Type  1  security,  but  it 
is  also  used  in  the  military  environment.  The  Sectera  INE  protects  all  levels  of  data,  from 
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Government  Classified  to  TS/SCI.  It  provides  confidentiality,  data  integrity,  peer 
identification,  authentication  and  mandatory/discretionary  access  control  services.  The 
Sectera  INE  is  software  configured,  using  the  new  Sectera  INE  Configuration  Manager 
and  is  keyed  using  material  supplied  by  the  U.S.  Government’s  Electronic  Key 
Management  System  (EKMS),  for  Type  1  products.36  The  Communications  Interfaces 
on  the  KG-235  are  two  RJ-45  10/100  Base  T  and  two  DB-9  Serial  Ports.  The  INE  can 
support  up  to  20  Mbps  of  aggregrate  data  throughput37  with  further  planned  upgrades 
making  that  number  even  higher. 

The  INEs  were  inserted  between  the  technology  link  and  the  LAN  Cisco 
3550  switch  on  both  LANs.  To  make  the  KG-235s  work  properly  within  the  network, 
they  had  to  replace  the  LAN  Cisco  3745  routers.  The  KG-235s  actually  function  as  a 
router,  but  when  assigning  the  IP  addresses  to  the  two  KG-235s  they  needed  to  be  on  the 
same  subnet  in  order  for  the  two  networks  to  see  each  other.  Finally,  one  of  the  two 
Ethernet  ports  on  the  KG-235s  was  used  to  go  to  the  link  equipment  with  CAT-5  cable 
and  the  other  one  went  to  the  LAN  Cisco  switch,  also  with  CAT-5  cable.  The  laptops 
were  also  connected  to  the  switch,  and  they  needed  to  have  an  IP  address  of  the  same 
subnet  as  the  KG-235s. 

Due  to  some  network  configuration  problems  with  the  KG-235s  and  one 
of  them  constantly  dropping  its  fill,  the  authors  were  unable  to  attain  any  data  with  the 
KG-235S. 

2.  Beyond  Line-of-Sight  (BLOS) 

Since  this  testing  evolution  at  GDDS  was  still  at  the  beginning  stages  of  the 
author’s  testing  phase,  they  had  not  yet  interacted  with  any  commercial  vendors  that 
produced  BLOS  technology.  Later  field  tests,  #3  and  #4,  demonstrated  an  Orthogonal 
Frequency  Division  Multiplexing  (OFDM)  technology  that  was  able  to  do  terrestrial 
BLOS.  Refer  to  those  testing  evolutions  for  the  results. 

3.  Over-the-Horizon  (OTH) 

With  this  being  the  first  major  testing  event  planned,  OTH  capable  technologies 
had  not  yet  been  researched  thoroughly.  However,  GDDS  did  offer  their  services  in  this 

36  http://www.gdc4s.cotn/Products/sectera.htm  (April  2004). 

37  http://webhome.idirect.cotn/~iproc/crvpto/kg235.html  (April  2004). 
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area  to  at  least  demonstrate  an  OTH  capability  between  the  two  LANs.  They  worked 
with  Dr.  Glenn  Abousleman  from  Arizona  State  University 
( glen.abousleman@gdds.com)  in  order  to  utilize  the  existing  Iridium  satellite  architecture 
to  its  fullest  capabilities.  Dr.  Abousleman’s  work  has  focused  on  utilizing  a  compression 
algorithm  over  this  limited  throughput  mode  of  transmission.  The  following  paragraphs 
further  explain  this  capability  and  how  it  is  encrypted  with  General  Dynamics’  INE. 

a.  Iridium  Inverse  Multiplexer  (IMUX) 

A  single  Iridium  channel  can  only  transfer  data  at  2.4  kbps  (not  sufficient 
for  image  and  video  transmission).  Reachback  IMUX  combines  four  2.4  Kbps  Iridium 
channels  to  increase  overall  bandwidth  to  9.6  Kbps.38  The  four  L-Band  transreceivers 
actually  feed  into  an  IMUX  box  that  can  be  seen  in  the  Figure  32  below. 


Figure  32.  IMUX39 


There  are  three  modes  of  operation  for  the  IMUX:  Data,  Video,  and 
Voice  transmission  mode.  The  data  mode  ensures  data  is  not  altered  during  transmission 
(data  files,  critical  imagery,  etc.).  The  video  transmission  mode  can  do  real-time  video 
transmission  using  custom  video  compression  software  (used  when  loss  of  video  quality 
can  be  tolerated).  Finally,  in  Voice  mode  each  Iridium  channel  can  be  used  as  a  satellite 
telephone.40 

The  compression  algorithm  that  Dr.  Abousleman  developed  can 
significantly  reduce  the  size  of  pictures  and  video  to  transmit  over  the  limited  throughput 
Iridium  links.  Through  this  compression,  the  user  can  actually  select  what  parts  of  a 
picture  or  video  to  compress,  such  as  background  around  the  main  area  of  interest,  and 
what  parts  to  not  apply  the  compression  to,  such  as  a  target  of  interest.  After 

38  Dr.  Glen  Abousleman,  “Iridium  Inverse  Multiplexer  (IMUX)  Brief’,  October  2003. 

39  Dr.  Glen  Abousleman,  “Iridium  Inverse  Multiplexer  (IMUX)  Brief’,  October  2003. 

40  Dr.  Glen  Abousleman,  “Iridium  Inverse  Multiplexer  (IMUX)  Brief’,  October  2003. 


61 


compressing,  Dr.  Abousleman  demonstrated  to  the  authors  in  a  prior  visit  that  the 
transmission  takes  only  seconds  to  go  from  one  computer,  through  the  satellite  links,  and 
down  to  another  computer. 

During  this  testing  evolution,  problems  occurred  with  the  one  of  the 
IMUX  ports  that  feeds  into  the  Iridium  transceiver  and  one  of  the  KG-235s  kept  dropping 
its  fdl.  Thus,  no  data  was  collected  with  the  Iridium  link.  Refer  to  Field  Test  #3  at 
Raytheon  to  read  about  the  success  of  this  experiment. 

b.  Crypto  (KG-23 5 INE) 

General  Dynamics’  KG-23 5  INE  was  explained  in  detail  above.  The  KG- 
23  5  is  needed  to  encrypt  and  decrypt  the  Iridium  satellite  link.  The  KG-23  5  was 
programmed  with  IP  addresses  exactly  the  same  as  mentioned  above  for  the  LAN  to  LAN 
communication.  Figure  33  demonstrates  the  setup  that  was  planned  for  this  testing 
evolution  with  the  IMUX.  The  only  difference  between  the  actual  setup  and  the  picture 
was  that  the  Cisco  3550  switch  was  between  the  clients  and  INE.  This  type  of  setup  was 
successful  at  Field  Test  #3  at  Raytheon.  See  the  next  section  for  this  information. 
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Figure  33.  IMUX  WITH  INE  INSERTED41 


In  summary,  this  testing  evolution  at  General  Dynamics  in  Scottsdale,  AZ 
proved  to  be  a  significant  learning  experience  for  the  authors  as  several  companies 
presented  their  products  for  demonstration;  and  they  connected  to  existing  LANs  that 
were  put  together  by  the  students.  The  technologies  evaluated  were  802.11b  over 
SecNet-11,  Microwave,  FSO,  802.16,  and  Iridium.  In  addition,  DSUs  and  VoIP  were 
inserted  with  success.  Finally,  the  Iridium  links  with  IMUX  and  the  KG-235s  did  not 
meet  expectations.  However,  a  great  deal  of  information  was  obtained  and  later  used  in 
order  to  accomplish  the  various  goals  in  the  next  field  test  at  Raytheon. 

C.  FIELD  TEST  #3  (RAYTHEON) 

Four  students  (Captain  Garcia,  Captain  Joseforsky,  Lieutenant  Seeman,  and 
Lieutenant  Cordero)  from  the  Naval  Postgraduate  School  conducted  the  third  field  test  for 
Marine  Corps  Systems  Command.  On  February  2-6,  the  students,  along  with  Raytheon 
and  several  vendors,  participated  in  communications  testing  for  the  Common  Aviation 
Command  and  Control  System  (CAC2S),  a  product  being  built  by  Raytheon.  The  testing 
compared  current  state-of-the-art  commercial  wireless  technologies  in  the  following 
areas:  operational  ease  of  use,  power  and  environmental  considerations,  and 
communication  bandwidth.  Each  technology  was  evaluated  for  CAC2S  node  to  CAC2S 
node  and  for  sub-system  intra-nodal  connectivity.  In  particular,  the  students  evaluated 
sub-system  connectivity  from  the  Processing  and  Display  Subsystem  (PDS)  to  the 
Communications  Subsystem  (CS)  and  sub-system  connectivity  from  the  PDS  to  the 
Sensor  and  Data  Subsystem  (SDS).  The  ultimate  goal  for  field  test  three  was  to 
determine  which  technologies  would  increase  throughput  on  the  battlefield  at  a  distance 
greater  than  six  kilometers.  The  following  connectivity  diagram  was  utilized  with  each 
technology  providing  the  connectivity  between  the  two  separate  LANs  (Figure  34). 


41  Dr.  Glen  Abousleman,  “Iridium  Inverse  Multiplexer  (IMUX)  Brief’,  October  2003. 
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Figure  34.  RAYTHEON  CONNECTIVITY  DIAGRAM 


The  following  state-of-the-art  wireless  technologies  were  tested:  Free  Space 
Optics,  802.11b  (over  SecNet-11),  802.16,  Orthogonal  Frequency  Division  Multiplexing 
(OFDM),  and  Microwave  Link.  Voice  over  Internet  Protocol  (VoIP)  was  implemented  in 
the  local  area  networks  to  test  which  technologies  handle  VoIP  best.  Finally,  the  students 
demonstrated  a  BLOS/OTH  capability  provided  by  combining  Iridium  satellite  channels. 
This  technology  is  used  in  the  Marine  Corps  Warfighting  Lab’s  Expeditionary  Tactical 
Communications  System.  Over  the  Iridium  link,  the  Iridium  Inverse  Multiplexer 
(IMUX)  and  Compression  Algorithm,  being  developed  by  Dr.  Glen  Abousleman,  was 
utilized.  The  figure  below  is  a  picture  of  some  of  the  wireless  technologies  examined  at 
Raytheon  testing,  the  products  are  (from  left  to  right)  the  Iridium  antenna  for  the  IMUX, 
RFM,  MRV’s  Terescope  5000,  and  the  parabolic  antenna  for  802.1  Ib  over  SecNet-II 
(Figure  35). 
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Figure  35.  REMOTE  SITE  WIRELESS  TECHNOLOGIES  AT  RAYTHEON 


One  of  the  lessons  learned  from  the  General  Dynamics  testing  was  to  use  an 
industry  standard  method  in  order  to  measure  throughput  over  the  link  being  tested.  The 
industry  standard  measurement  used  was  SmartBits  by  Spirent  Communications.  The 
SmartBits  analysis  system  is  the  industry  standard  for  high  port  density  testing.42 
According  to  the  Spirent  web  site,  “SmartBits  enables  you  to  test,  simulate,  analyze, 
troubleshoot,  develop,  and  certify  network  infrastructure.”43  Prior  to  actual  testing  at 
Raytheon,  the  students  were  able  to  get  a  few  days  of  hands-on  SmartBits  training.  The 
capabilities  and  analysis  results  were  explained  and  demonstrated  (one  time)  by  Spirent 
personnel.  The  SmartBits  system  consisted  of  two  chassis  that  simulated  data,  voice,  and 
video  among  several  users.  With  this  new  tool  in-hand,  the  students  were  ready  to 
conduct  some  testing  at  Raytheon. 

The  following  paragraphs  will  explain  each  technology  by  either  LOS,  BEOS,  or 
OTH  chronologically. 

1.  Line-of-Sight  (LOS) 
a.  Lightpointe 


42  http://www.spirentcom.com/analysis/product_line.cfm?wt=2&az-c=pl&PL=33 

43  http://www.spirentcom.com/analysis/product_line.cfm?wt=2&az-c=pl&PL=33 
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Lightpointe  was  the  first  company  tested  because  they  were  local  and  they 
were  available  to  assist  in  the  baseline  testing.  The  personnel  from  Lightpointe  that 
assisted  in  this  field  test  were  Jim  McGowen,  Director  of  Sales;  and  Albert  Borquez, 
Senior  Network  Engineer.  The  product  Lightpointe  brought  was  the  FlightStrata-155M. 
The  baseline  testing  was  conducted  to  ensure  that  the  local  area  networks  were  operating 
correctly  and  to  ensure  the  logistical  items  (tent,  remote  power,  power  on  the  roof  of 
Raytheon,  etc...)  were  in  place.  Many  factors,  including  weather  and  distance,  initially 
challenged  this  testing  evolution.  The  testing  conducted  on  the  first  day,  2  February,  was 
limited.  The  table  below  represents  two  SolarWinds  raw  data  points  which  were  taken 
late  into  the  night  (Table  21). 


Table  2 1 .  FSO  BASELINE  AT  RAYTHEON 


In  addition  to  the  data  monitored  by  SolarWinds,  raw  data  points  were 
taken  using  Iperf.  Iperf  is  a  bandwidth  measuring  tool  used  to  measure  end-to-end 
bandwidth  by  using  Transport  Control  Protocol  (TCP)  streams.44  The  raw  data  below 
represents  some  Iperf  measurements  taken  on  February  2: 


Server  listening  on  TCP  port  5001 
TCP  window  size:  8.0  KByte  (default) 


[108]  local  192.168.1.2 
[  ID]  Interval 
[108]  0.0-20.0  sec 
[928]  15.0-20.2  sec 
[928]  0.0-21.1  sec 


port  5001  connected  with  192.168.3.3  port  1054 


Transfer 
89.7  MBytes 
864  KBytes 
3.5  Mbytes 


Bandwidth 
35.8  Mbits/sec 
1.3  Mbits/sec 
1.3  Mbits/sec 


44  Ajay  Tirumala,  Les  Cottrell,  Tom  Dunigan:  “Measuring  end-to-end  bandwidth  using  Iperf  using 
Web  100”  *under  Iperf  folder 
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Looking  at  the  throughput  summary  data  provided  by  SmartBits  (Table 
22,  below),  it  is  clear  to  see  the  frame  loss.  The  table  shows  the  frame  size  measured  in 
Mbytes,  the  throughput  percentage  max  load  shows  the  amount  of  data  being  processed 
across  the  link  (measured  in  Mbytes),  and  the  frame  loss  shows  the  percentage  of  packets 
lost  in  transition  between  the  two  chassis.  The  frame  loss  measured  in  this  run  resulted 
from  operating  in  the  rain  and  in  the  dark  over  a  large  distance.  This  testing  was 
conducted  around  2000  hours  under  rainy  conditions. 


FrameSize 

128 

192 

256 

320 

384 

448 

512 

576 

Throughput  (%  max  load) 

10 

10 

10 

10 

10 

10 

10 

10 

Frame  Loss  (%) 

0.07 

1.33 

0.86 

0 

29.6 

0 

0 

0 

FrameSize 

640 

704 

768 

832 

896 

960 

1024 

1088 

Throughput  (%  max  load) 

10 

10 

10 

10 

20 

10 

20 

10 

Frame  Loss  (%) 

1.93 

0 

21.2 

4.01 

0 

8.79 

0 

5.88 

FrameSize 

1152 

1216 

1280 

1344 

1408 

1472 

Throughput  (%  max  load) 

10 

10 

20 

10 

10 

10 

Frame  Loss  (%) 

6.45 

0 

0 

16.6 

0 

0 

Table  22.  SMARTBITS  RAYTHEON  BASELINE  TESTING 


The  figure  below  is  a  product  of  SmartBits.  The  figure  gives  a  graphical 
representation  of  throughput  versus  frame  loss  (Figure  35). 
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X 

o' 

Throughput  vs  Frame  Size 

Figure  36.  SMARTBITS  RAYTHEON  BASELINE  GRAPHICS 

On  3  February,  conneetivity  between  the  two  sites  was  again  established 
with  Lightpointe’s  product.  The  weather  was  hazy  with  light  rain.  The  SolarWinds  data 
taken  was  a  measure  of  data  files  (Power  Point,  Word  documents.  Excel,  and  Adobe 
documents)  being  transferred  from  one  LAN  to  another  LAN.  The  following  data  was 
obtained  using  SolarWinds  (Table  23). 
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Run  No. 

Media 

Size 

Time 

Throughput 

Loss  (%) 

VOICE 

VIDEO 

1 

FSO 

1.5  M 

1" 

2.2M 

0 

NO 

NO 

2 

FSO 

5  M 

7" 

7M 

0 

NO 

NO 

3 

FSO 

10  M 

2" 

14M 

0 

NO 

NO 

4 

FSO 

Iperf 

40M 

0 

NO 

NO 

5 

FSO 

75  M 

15" 

35M 

0 

NO 

NO 

6 

FSO 

150  M 

42" 

38M 

0 

NO 

NO 

7 

FSO 

300  M 

1’24" 

36M 

0 

NO 

NO 

8 

FSO 

600  M 

2'30" 

38M 

0 

NO 

NO 

9 

FSO 

1.2  GIG 

5'30" 

37M 

0 

NO 

NO 

Table  23.  1 

LIGHTPO 

INTE  AT  RAYTHEON 

The  following  Iperf  data  points  were  taken  immediately  following  the 
SolarWinds  data: 


Client  connecting  to  192.168.1.2,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.3.3 
[  ID]  Interval 
[928]  0.0- 5.0  sec 
[928]  5.0-10.0  sec 
[928]  10.0-15.0  sec 
[928]  15.0-20.0  sec 
[928]  0.0-20.0  sec 


port  1054  connected  with  192.168.1.2  port  5001 


Transfer 
22.8  MBytes 
22.8  MBytes 

21.5  MBytes 

22.6  MBytes 

89.7  MBytes 


Bandwidth 
36.5  Mbits/sec 
36.5  Mbits/sec 
34.3  Mbits/sec 
36.1  Mbits/sec 
35.8  Mbits/sec. 


The  data  below  describes  the  load,  throughput. 


packets  sent,  packets 


received,  packets  lost,  and  the  percent  of  lost  packets.  A  throughput  summary  of  the 
detailed  data  produced  by  SmartBits  is  as  follows  (Table  24). 


Total 

10 

10 

16200 

16198 

2 

0.01235 

Data  Group 

N/A 

10 

16200 

16198 

2 

0.01235 

Total 

20 

20 

32500 

32500 

0 

0 

Data  Group 

N/A 

20 

32500 

32500 

0 

0 

Total 

30 

20 

48700 

35389 

13311 

27.3327 

Data  Group 

N/A 

20 

48700 

35389 

13311 

27.3327 

Table  24.  LIGHTPOINTE’S  SMARTBITS  DATA  AT  RAYTHEON 
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An  example  of  a  portion  of  a  detailed  data  run  for  Lightpointe  is 
demonstrated  in  Table  25  below.  This  table  demonstrates  how  data  is  simulated  across 
the  network.  One  port  on  Data  One  sends  data  to  fifty  different  ports  on  Data  Two.  In 
return  a  port  on  Data  Two  sends  data  to  fifty  ports  on  Data  One.  The  example  in  Table  25 
shows  a  transfer  of  data.  This  system  has  the  capability  to  simulate  data,  voice,  and  video 
as  well. 


Total 

10 

10 

16200 

16198 

2 

0.01235 

Data  Group 

N/A 

10 

16200 

16198 

2 

0.01235 

Data 

1518 

0.2 

10 

162 

162 

0 

0 

Data 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-2 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-3 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-4 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-5 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-6 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-7 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-8 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-9 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-10 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-11 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-12 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-13 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-14 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-15 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-16 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-17 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-18 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-19 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-20 

1518 

0.2 

10 

162 

162 

0 

0 

Data  1:1-1->2:1-1-21 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-22 

1518 

0.2 

10 

162 

162 

0 

0 

Data  l:l-l->2:l-l-23 

1518 

0.2 

10 

162 

161 

1 

0.61728 

Data  l:l-l->2:l-l-24 

1518 

0.2 

10 

162 

161 

1 

0.61728 

Data  l:l-l->2:l-l-25 

1518 

0.2 

10 

162 

162 

0 

0 

Table  25 .  PORTION  OF  LIGHl 

rPOINTE  ] 

DATA  RUN  AT  RAYTHEON 
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Figure  36  is  a  graphic  product  of  SmartBits.  The  graphic  visually  shows 
the  throughput  and  frame  loss  of  the  infrastructure.  The  visual  representation  clearly 
shows  a  frame  size  of  1,518  Kbytes  with  a  throughput  of  20  Mbps. 


100-1 - 

r-ii—i 

Throughput  (%  max  load)' 

80 

70 
60 
50 
40 
30 
20 
10 
0 

1518 


Throughput  vs  Frame  Size 

Figure  37.  LIGHTPOINTE  THROUGHPUT  VERSUS  FRAME  SIZE  AT  RAYTHEON 
b.  SecNet-11 

Testing  of  an  802.1  lb  technology  (SecNet-1 1)  was  conducted  on  February 
2-3,  2004.  The  configuration  was  the  same  as  described  in  Field  Test  Two.  The  testing 
was  conducted  at  a  range  of  6.7  kilometers.  Each  bridge  was  encrypted  with  a  SecNet-1 1 
card.  One  side  of  the  bridge  was  connected  to  the  parabolic  antenna  and  the  other  side  of 
the  bridge  was  connected  the  network.  The  special  connectors  interfacing  the  bridge  and 
the  parabolic  antenna  and  the  speed  of  the  ports  of  the  routers  and  the  switches  described 
in  Field  Test  Two  apply  in  the  configuration  of  this  experiment.  The  channel  setting  for 
the  bridge  was  channel  eleven. 

It  was  raining  on  2  February,  the  night  of  the  baseline  testing.  Due  to  the 
late  start,  data  collected  on  this  day  was  limited.  There  were  only  three  data  points 
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collected  using  SolarWinds  and  one  Iperf  data  point  was  collected.  The  table  below 
(Table  26)  shows  the  data  collected  on  Febraary  2-3  from  the  transfer  data  test  monitored 
by  SolarWinds.  On  the  fourth  run,  the  Iperf  test  was  done  in  conjunction  with  the 
transfer  data  test. 


Run  No. 

Media 

Size 

Time 

Throughput 

From 

To 

VOICE 

1 

802.11b 

10  M 

1.54M 

3.3 

1.2 

NO 

2 

802.11b 

25  M 

3'00" 

1.55M 

3.3 

1.2 

NO 

3 

802.11b 

126M 

1.62M 

3.3 

1.2 

NO 

Table  26.  SECNET  1 1  SOLARWINDS  DATA  FEBRUARY  2-3 


The  Iperf  data  was  collected  prior  to  securing  for  the  night  on  2  February. 
The  following  represents  the  Iperf  data  collected: 


Client  connecting  to  192.168.1.3,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928] 

[ID] 

[928] 

[928] 

[928] 

[928] 

[928] 


local  192.168.3.3 
Interval 
0.0-  5.0  sec 
5.0-10.0  sec 
10.0-15.0  sec 
15.0-20.2  sec 
0.0-21.1  sec 


port  1033  connected  with  192.168.1.3  port  5001 
Transfer 
688  KBytes 
1 .0  MBytes 
960  KBytes 
864  KBytes 
3.5  MBytes 


Bandwidth 
1.1  Mbits/sec 
1.6  Mbits/sec 
1.5  Mbits/sec 
1.3  Mbits/sec 
1.3  Mbits/sec 


On  3  February,  the  wind  was  blowing  at  roughly  15  knots.  The  first 
couple  of  hours  were  spent  erecting  the  tent  and  securing  the  antennas  at  the  remote  site. 
The  antenna  at  the  remote  site  was  tied  off  with  a  guy  wire  that  was  then  secured  into  the 
ground  using  tent  stakes.  The  parabolic  antenna  at  the  remote  site  was  very  stable  and 
did  not  move,  but  keeping  the  parabolic  antenna  stable  on  the  roof  of  the  Raytheon 
building  was  a  challenge.  The  antenna  was  eventually  secured  by  having  an  individual 
hold  the  antenna  in  the  direction  of  the  remote  site.  The  data  table  above  (Table  26) 
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shows  the  only  data  point  taken  using  SolarWinds.  The  following  Iperf  data  rans  indicate 
lower  throughput  mainly  because  of  the  wind  conditions.  According  to  the  Certified 
Wireless  Network  Administrator  Official  Study  Guide,  “Wind  does  not  affect  radio 
waves  or  an  RF  signal,  but  it  can  affect  the  positioning  and  mounting  of  outdoor 
antennas.... A  strong  wind  could  easily  move  one  or  both  antennas  enough  to  completely 
degrade  the  signal  between  the  two  antennas.  This  effect  is  called  ‘antenna  wind 
loading.  ”’45  The  figure  below  shows  an  example  of  antenna  wind  loading  (Figure  37). 


Beam  arrives 


Beam  misses 


Figure  38.  ANTENNA  WIND  LOADING46 


Only  two  runs  were  conducted  due  to  the  bad  wind  conditions.  In 
comparison  to  the  night  before  when  the  wind  was  not  as  strong,  the  throughput  was 
considerably  less  on  the  windy  day.  The  following  represents  the  data  obtained  from  the 
Iperf  test: 


Client  connecting  to  192.168.1.2,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.3.3  port  1113  connected  with  192.168.1.2  port  5001 
[  ID]  Interval  Transfer  Bandwidth 

[928]  0.0-14.2  sec  72.0  KBytes  40.5  Kbits/sec 

45  McGraw-Hill/Osbome,  “Certified  Wireless  Network  Administrator  Offieial  Study  Guide  (Exam 
PWO-100)  Second  Edition”,  (Berkeley,  California:  PlanetS  Wireless,  Inc.  2003),  pg  357. 

46  Ibid  McGraw-Hill/Osbome,  “Certified  Wireless  Network  Administrator  Official  Study  Guide 
(Exam  PWO-100)  Second  Edition”,  (Berkeley,  California:  Planet3  Wireless,  Inc.  2003),  pg  357. 
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[928]  14.2-14.2  sec  8.0  KBytes 

[928]  14.2-15.1  sec  24.0  KBytes 

[928]  15.1-20.0  sec  160  KBytes 

[928]  0.0-20.8  sec  264  KBytes 


Inf  s/sec 
228  Kbits/sec 
258  Kbits/sec 
101  Kbits/sec 


SECOND  RUN 


Client  connecting  to  192.168.1.2,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.3.3  port  1114  connected  with  192.168.1.2  port  5001 


[  ID]  Interval 

Transfer 

Bandwidth 

[928]  0.0- 5.2  sec 

360  KBytes 

549  Kbits/sec 

[928]  5.2-10.1  sec 

280  KBytes 

464  Kbits/sec 

[928]  10.1-15.3  sec 

320  KBytes 

486  Kbits/sec 

[928]  15.3-20.1  sec 

272  KBytes 

460  Kbits/sec 

[928]  0.0-33.8  sec 

1 .2  MBytes 

292  Kbits/sec 

On  the  following  day  a  different  technology,  802.16,  was  tested  along  with 
FSO.  The  802.16  company  was  Ensemble  Communications  and  the  FSO  company  was 
Terabeam.  This  testing  is  explained  in  the  next  two  section  of  this  thesis. 

c.  Ensemble 

Ensemble  Communications  brought  equipment  that  utilizes  802.16 
technology.  As  described  earlier  in  this  thesis,  802.16  technology  is  used  for  WANs.  In 
the  commercial  sector,  802.16  is  used  for  backhaul  broadband  wireless  connectivity  for 
many  service  providers.  The  personnel  who  supported  this  evolution  were  Jeff 
Nightingale,  Sales  Director;  Corey  Koberg,  Engineer;  and  Jerry  Shirey,  Field  Technician. 
As  discussed  in  the  General  Dynamics  exercise,  Field  Test  Two,  Ensemble’s  system  was 
ATM  based  which  means  that  special  configurations  for  both  local  area  networks  needed 
to  take  place  prior  to  any  testing.  At  the  Mobile  Research  Facility,  a  single  port  ATM 
OC-3  Single-mode  Intermediate  Reach  NM  card  for  the  Cisco  3745  router  was 
configured  for  the  router.  The  16200  Hub  Station  was  connected  to  the  port  on  this  card 
with  a  single-mode  fiber  cable.  At  the  remote  site,  the  320  Multiplexer  was  connected  to 
the  remote  Cisco  3745  router  with  CAT-5  cable.  Similar  to  Field  Test  Two,  a  Fiberless 
282  Series  ODU  was  utilized  for  the  antenna. 
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The  series  of  tests  that  were  conducted  with  Ensemble  started  with  Iperf 
testing,  followed  by  SolarWinds  testing,  and  concluded  with  SmartBits  testing.  The  Iperf 
testing  was  conducted  after  the  two  ends  were  configured  to  handle  an  ATM  based 
network.  The  Iperf  data  is  represented  below: 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1  MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168.1.2  port  1038 

[  ID]  Interval  Transfer  Bandwidth 

[920]  0.0- 1.0  sec  2.4  MBytes  19.4  Mbits/sec 

[920]  1.0- 2.0  sec  2.8  MBytes  22.7  Mbits/sec 

[920]  2.0-  3.0  sec  3.0  MBytes  24.0  Mbits/sec 

[920]  3.0- 4.0  sec  3.1  MBytes  24.6  Mbits/sec 

[920]  4.0-  5.0  sec  3.2  MBytes  25.5  Mbits/sec 

[920]  5.0- 6.0  sec  4.0  MBytes  32.1  Mbits/sec 

[920]  6.0-  7.0  sec  4.5  MBytes  35.9  Mbits/sec 

[920]  7.0-  8.0  sec  4.5  MBytes  35.9  Mbits/sec 

[920]  8.0-  9.0  sec  4.5  MBytes  35.9  Mbits/sec 

[920]  9.0-10.0  sec  4.5  MBytes  35.9  Mbits/sec 

[920]  0.0-10.0  sec  36.5  MBytes  29.2  Mbits/sec 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1  MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168.1.2  port  1041 

[  ID]  Interval  Transfer  Bandwidth 

[920]  0.0- 1.0  sec  3.3  MBytes  26.2  Mbits/sec 

[920]  1.0- 2.0  sec  4.5  MBytes  36.0  Mbits/sec 

[920]  2.0-  3.0  sec  4.5  MBytes  35.9  Mbits/sec 

[920]  3.0-  4.0  sec  3.9  MBytes  30.8  Mbits/sec 

[920]  4.0- 5.0  sec  3.1  MBytes  24.5  Mbits/sec 

[920]  5.0- 6.0  sec  3.1  MBytes  24.2  Mbits/sec 

[920]  6.0- 7.0  sec  3.1  MBytes  25.7  Mbits/sec 

[920]  7.0-  8.0  sec  3.2  MBytes  25.6  Mbits/sec 

[920]  8.0-  9.0  sec  3.4  MBytes  27.3  Mbits/sec 

[920]  9.0-10.0  sec  3.7  MBytes  29.9  Mbits/sec 

[920]  0.0-10.0  sec  35.9  MBytes  28.6  Mbits/sec 
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The  Iperf  data  for  the  first  run  indicated  an  average  throughput  of  29.2  Mbps  between  the 
two  sites  at  a  distance  of  6.7  kilometers.  The  Iperf  data  for  the  second  run  indicated  a 
throughput  of  28.6  Mbps  between  sites. 


The  measurements  observed  using  SolarWinds  differ  from  the  readings 
indicated  by  Iperf  The  disparity  is  due  to  the  type  of  data  that  is  sent  across  the  link.  In 
the  Iperf  test,  the  size  of  the  data  being  transferred  is  a  consistent  steady  stream  of  data 
going  across  the  network.  In  the  transfer  data  test  monitored  by  SolarWinds,  the  data 


going  across  the  network  differs  in  size  of  the  file  and  the  type  of  data.  The  SolarWinds 


results  are  represented  below  (Table  27). 


Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Loss  (%) 

VOICE 

VIDEO 

1 

802.16 

1.5  M 

1" 

2.2M 

0 

NO 

NO 

2 

802.16 

5M 

8" 

6.28M 

0 

NO 

NO 

3 

802.16 

lOM 

13" 

7.84M 

0 

NO 

NO 

5 

802.16 

75  M 

1'20" 

7.9M 

0 

NO 

NO 

6 

802.16 

150  M 

3'00" 

7M 

0 

NO 

NO 

7 

802.16 

video 

6.46M 

0 

YES 

YES 

8 

802.16 

video 

3M 

0 

YES 

YES 

9 

802.16 

video  both 

sides 

6M 

0 

YES 

YES 

10 

802.16 

video 

and  75M 

7M 

0 

YES 

YES 

Table  27. 


ENSEMBLE  RAW  SOLARWINDS  DATA  AT  RAYTHEON 


The  data  obtained  using  SmartBits  resembles  the  data  obtained  from  using 
Iperf  Four  different  runs  were  tested  using  SmartBits.  The  first  run  was  to  observe 
where  the  maximum  throughput  was  located.  The  second  run  was  to  determine  where 
SolarWinds  was  dropping  the  link  (SolarWinds  would  indicate  the  link  was  not 
established,  however,  the  link  was  still  up  because  we  were  able  to  use  VoIP).  The  third 
run  was  to  measure  the  amount  of  packet  loss  when  the  throughput  was  doubled.  The 
fourth  run  was  to  examine  the  link  with  an  over-saturation  of  data. 

The  maximum  throughput  was  located  in  a  range  of  20-30  Mbps,  similar 
to  what  Iperf  produced.  The  data  table  below  shows  an  excerpt  of  the  data  obtained  from 

the  SmartBits  program  in  the  first  run  (Table  28). 
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Total 

10 

10 

16218 

16218 

0 

0 

Data  Group 

N/A 

10 

15900 

15900 

0 

0 

TEST  Group 

N/A 

10 

318 

318 

0 

0 

Total 

20 

20 

32436 

32433 

3 

0.00925 

Data  Group 

N/A 

20 

31800 

31797 

3 

0.00943 

TEST  Group 

N/A 

20 

636 

636 

0 

0 

Total 

30 

20 

48756 

37589 

11167 

22.90385 

Data  Group 

N/A 

20 

47800 

36867 

10933 

22.87238 

TEST  Group 

N/A 

20 

956 

722 

234 

24.47699 

FrameSize 

1518 

Throughput  (%  max  load) 

20 

Frame  Loss  (%) 

0.00925 

Table  28.  ENSEMBLE  SMAR' 


BITS  DATA  AT  RAYTHEON 


The  figure  below  shows  a  graphic  representation  of  the  throughput  of 
SmartBits.  This  graphic  representation  indicates  there  was  no  packet  loss  in  the  above 
test  when  the  load  was  at  20  Mbps  (Figure  38). 

100-1 - 1 

r-ii—i 

Throughput  (%  max  load) 

80 

70 
60 
50 
40 
30 
20 
10 
0 


1518 


Throughput  vs  Prams  Sizs 

Figure  39.  ENSEMBLE  SMART  BITS  GRAPHICS  AT  RAYTHEON 
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The  third  run  using  Smart  Bits  was  an  experiment  to  determine  the  amount 
of  packet  loss  if  the  throughput  load  was  doubled.  The  data  indicated  that  when  the 
throughput  was  doubled  (the  amount  of  data  being  sent  was  two  times  the  size  of  the  20- 
30  Mbps  throughput  being  allowed  by  Ensemble’s  equipment),  the  packet  loss  increased. 
The  table  below  indicates  the  results  obtained  on  the  third  run  (Table  29). 


Total 

10 

10 

16218 

16218 

0 

0 

Data  Group 

N/A 

10 

15900 

15900 

0 

0 

TEST  Group 

N/A 

10 

318 

318 

0 

0 

Total 

20 

20 

32436 

32435 

1 

0.00308 

Data  Group 

N/A 

20 

31800 

31799 

1 

0.00314 

TEST  Group 

N/A 

20 

636 

636 

0 

0 

Total 

30 

30 

48756 

37587 

11169 

22.90795 

Data  Group 

N/A 

30 

47800 

36841 

10959 

22.92678 

TEST  Group 

N/A 

30 

956 

746 

210 

21.96653 

Total 

40 

40 

64974 

37571 

27403 

42.17533 

Data  Group 

N/A 

40 

63700 

36814 

26886 

42.20722 

TEST  Group 

N/A 

40 

1274 

757 

517 

40.58085 

Total 

50 

40 

81192 

37556 

43636 

53.74421 

Data  Group 

N/A 

40 

79600 

36908 

42692 

53.63317 

TEST  Group 

N/A 

40 

1592 

648 

944 

59.29648 

FrameSize 

1518 

Throughput  (%  max  load) 

40 

Frame  Loss  (%) 

42.17533 

Table  29.  ENSEMBLE  SMARTBITS  DATA  (X2)  AT  RAYTHEON 


The  graphic  illustration  below  compares  the  throughput  and  the  frame  loss 
during  the  third  run  (Figure  39). 
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Figure  40.  ENSEMBLE  PACKET  LOSS  AT  RAYTHEON 

The  second  run  will  be  covered  in  the  Findings  and  Analysis  portion  of  the 
thesis  because  these  runs  focused  on  why  the  link  dropped  out  between  the  30  to  40  Mbps 
phase  of  the  experiment.  The  fourth  run  will  be  covered  in  the  Findings  and  Analysis 
portion  also  because  the  data  is  similar  to  the  results  obtained  in  the  third  run  (saturation 
of  the  network).  The  third  run  indicated  that  when  the  network  is  oversaturated,  then  an 
increase  of  packet  loss  is  observed.  This  is  to  say  that  there  is  an  upper  limit  of  data  that 
can  be  processed  by  the  medium  providing  the  link  between  the  networks.  Once  this 
upper  limit  is  reached  then  the  network  will  experience  packet  loss. 

FSO  was  also  tested  on  the  same  day.  The  name  of  the  company  tested 
was  Terabeam  from  Redmond,  Washington. 

d.  Terabeam 

Terabeam  produces  FSO  equipment  as  well  as  Radio  Frequency  (RF) 
equipment.  Their  RF  product  is  a  60  GHz  millimeter  wave  (MMW)  system.  The  FSO 
product  that  was  brought  was  the  Elliptica.  The  difference  between  this  company  and  the 


79 


other  companies  is  that  Terabeam’s  product  uses  only  one  laser  at  the  1550  nanometer 
wavelength.  Other  impressive  features  of  the  Elliptica  are  the  optical  scope,  the  auto 
tracking  feature,  and  the  easy  setup.  The  optical  scope  was  used  to  align  the  two  lasers. 
The  alignment  process  took  a  total  of  5  minutes.  The  auto-tracking  feature  compensates 
for  the  swaying  of  buildings  or  the  movement  of  the  distant  laser.  The  setup  of  the 
Elliptica  was  done  quickly  and  efficiently.  The  Elliptica  comes  with  deployable  mounts 
used  to  set  the  optical  head  (Figure  40). 


Figure  4 1 .  TERABEAM  ELLIPTICA 


The  Terabeam  personnel  who  supported  the  Raytheon  Testing  were  Pascal 
Boudreau,  Eric  Ruberg,  and  Carrie  Cornish.  Their  level  of  expertise  and  professionalism 
shined  throughout  the  testing  evolution. 

Similar  to  the  other  products  tested,  Terabeam  followed  the  same  series  of 
tests.  The  series  of  tests  consisted  of  taking  data  from  an  Iperf  test,  a  file  transfer  test 
(SolarWinds  data),  and  a  SmartBits  test.  When  the  Iperf  test  was  conducted,  setting  the 
window  size  of  the  data  being  transferred  was  very  important.  If  the  window  size  was 
too  low,  the  data  throughput  would  result  in  a  lower  value.  An  example  of  this  is 
demonstrated  in  the  Findings  and  Analysis  portion  of  the  thesis.  The  Iperf  data  obtained 
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on  Terabeam  was  one  of  the  highest  obtained  at  Raytheon.  The  data  below  represents  the 
Iperf  data  taken  on  Terabeam: 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168.1.2  port  1059 


[ID]; 

Interval 

Transfer 

Bandwidth 

[920] 

0.0-  1.0  sec 

8.7  MBytes 

69.7  Mbits/sec 

[920] 

1.0-  2.0  sec 

9.8  MBytes 

78.4  Mbits/sec 

[920] 

2.0-  3.0  sec 

9.7  MBytes 

77.4  Mbits/sec 

[920] 

3.0-  4.0  sec 

10.7  MBytes 

85.3  Mbits/sec 

[920] 

4.0-  5.0  sec 

10.2  MBytes 

81.3  Mbits/sec 

[920] 

5.0-  6.0  sec 

9.5  MBytes 

76.3  Mbits/sec 

[920] 

6.0-  7.0  sec 

10.9  MBytes 

88.3  Mbits/sec 

[920] 

7.0-  8.0  sec 

10.9  MBytes 

87.2  Mbits/sec 

[920] 

8.0-  9.0  sec 

11.3  MBytes 

90.2  Mbits/sec 

[920] 

9.0-10.0  sec 

10.9  MBytes 

87.0  Mbits/sec 

[920] 

0.0-10.0  sec 

10.3  MBytes 

82.1  Mbits/sec 

The  next  series 

of  testing  involved  the  transfer  of  data  files  that  would  be 

found  on  the  battlefield.  These  files  include  Power  Point,  Excel,  Word,  Adobe,  and  basic 
text  files  being  transferred  from  one  computer  in  one  local  area  network  to  another 
computer  in  another  local  area  network.  SolarWinds  was  used  to  monitor  the  data 
transfer.  There  were  nine  different  runs  conducted  during  this  data  testing  evolution. 
The  first  seven  runs  were  simple  data  transfer  between  the  two  local  area  networks 
measuring  throughput  and  time  for  the  data  to  be  transferred.  The  next  series  of  data 
runs,  VoIP  and  video  programs  were  running  on  the  computers  while  executing  the  data 
file  transfer  test.  The  purpose  of  these  runs  was  to  see  if  other  applications  had  an  effect 
on  the  throughput  of  the  data  being  transferred.  The  result  was  that  there  was  no  loss  in 
audio  quality  in  the  VoIP  and  no  loss  in  the  video  quality  of  the  videos  being  played  on 
the  computers  during  the  transfer.  The  data  below  represents  the  data  transfer  from  one 
local  area  network  to  the  other  local  area  network  via  Terabeam’s  link  (Table  30). 
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Run  No. 

Media 

Size 

Time 

Throughput 

Packet  Loss  (%) 

VOICE 

VIDEO 

1 

FSO 

1.5  M 

1” 

2.2M 

0 

NO 

NO 

2 

FSO 

5M 

6” 

7.29M 

0 

NO 

NO 

3 

FSO 

10  M 

2” 

14M 

0 

NO 

NO 

4 

FSO 

25  M 

1” 

18M 

0 

NO 

NO 

5 

FSO 

75  M 

F08” 

24M 

0 

NO 

NO 

6 

FSO 

150  M 

1T2” 

35M 

0 

NO 

NO 

7 

FSO 

300  M 

3’56” 

36M 

0 

NO 

NO 

8 

FSO 

5M 

6M 

0 

YES 

YES 

9 

FSO 

5M 

6M 

0 

YES 

YES 

Table  30.  TERABEAM’S  SOLAR  WIND  DATA  AT  RAYTHEON 


There  were  two  runs  using  SmartBits  for  the  Terabeam  produet.  The  first 
run  was  eonducted  to  measure  the  data  transfer  between  the  two  LANs.  The  data  is 
represented  below  (Table  31). 
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Total 

10 

10 

16218 

16210 

8 

0.04933 

Data  Group 

N/A 

10 

15900 

15892 

8 

0.05031 

Smart  Bit  Group 

N/A 

10 

318 

318 

0 

0 

Total 

20 

20 

32436 

32433 

3 

0.00925 

Data  Group 

N/A 

20 

31800 

31797 

3 

0.00943 

Smart  Bit  Group 

N/A 

20 

636 

636 

0 

0 

Total 

30 

30 

48756 

48740 

16 

0.03282 

Data  Group 

N/A 

30 

47800 

47784 

16 

0.03347 

Smart  Bit  Group 

N/A 

30 

956 

956 

0 

0 

Total 

40 

40 

64974 

64963 

11 

0.01693 

Data  Group 

N/A 

40 

63700 

63690 

10 

0.0157 

Smart  Bit  Group 

N/A 

40 

1274 

1273 

1 

0.07849 

Total 

50 

50 

81192 

81169 

23 

0.02833 

Data  Group 

N/A 

50 

79600 

79579 

21 

0.02638 

Smart  Bit  Group 

N/A 

50 

1592 

1590 

2 

0.12563 

Total 

60 

60 

97512 

97486 

26 

0.02666 

Data  Group 

N/A 

60 

95600 

95576 

24 

0.0251 

Smart  Bit  Group 

N/A 

60 

1912 

1910 

2 

0.1046 

Total 

70 

70 

113730 

113652 

78 

0.06858 

Data  Group 

N/A 

70 

111500 

1 1 1424 

76 

0.06816 

Smart  Bit  Group 

N/A 

70 

2230 

2228 

2 

0.08969 

Total 

80 

80 

129948 

129877 

71 

0.05464 

Data  Group 

N/A 

80 

127400 

127329 

71 

0.05573 

Smart  Bit  Group 

N/A 

80 

2548 

2548 

0 

0 

Total 

90 

90 

146268 

146174 

94 

0.06427 

Data  Group 

N/A 

90 

143400 

143309 

91 

0.06346 

Smart  Bit  Group 

N/A 

90 

2868 

2865 

3 

0.1046 

Total 

100 

100 

162486 

161946 

540 

0.33234 

Data  Group 

N/A 

100 

159300 

158764 

536 

0.33647 

Smart  Bit  Group 

N/A 

100 

3186 

3182 

4 

0.12555 

FrameSize 

1518 

Throughput  (%  max  load) 

100 

Frame  Loss  (%) 

0.33234 

Table  3 1 .  TERABEAM’ S  SMART  BITS  DATA  TRANSFER 


The  graphical  representation  shown  below  is  a  graph  of  throughput  versus 
frame  size  (Figure  41). 


100 


1518 


Throughput  vs  Frame  Size 

Figure  42.  TERABEAM  GRAPHICAL  DATA  REPRESENTATION 

The  next  run  of  testing  included  the  VoIP  function  of  SmartBits.  The 
SmartBits  equipment  generated  data  packets  along  with  VoIP  packets  across  the 
Terabeam  link.  The  data  below  represents  the  SmartBits  data  obtained  while  employing 
the  VoIP  function  with  Terabeam’s  link  (Table  32). 
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Total 

10 

10 

16224 

16221 

3 

0.01849 

Data  Group 

N/A 

10 

15600 

15597 

3 

0.01923 

Smart  Bit  Group 

N/A 

10 

312 

312 

0 

0 

VoIP  Group 

N/A 

10 

312 

312 

0 

0 

Total 

20 

20 

32448 

32435 

13 

0.04006 

Data  Group 

N/A 

20 

31200 

31187 

13 

0.04167 

Smart  Bit  Group 

N/A 

20 

624 

624 

0 

0 

VoIP  Group 

N/A 

20 

624 

624 

0 

0 

Total 

30 

30 

48672 

48657 

15 

0.03082 

Data  Group 

N/A 

30 

46800 

46785 

15 

0.03205 

Smart  Bit  Group 

N/A 

30 

936 

936 

0 

0 

VoIP  Group 

N/A 

30 

936 

936 

0 

0 

Total 

40 

40 

65000 

64990 

10 

0.01538 

Data  Group 

N/A 

40 

62500 

62490 

10 

0.016 

Smart  Bit  Group 

N/A 

40 

1250 

1250 

0 

0 

VoIP  Group 

N/A 

40 

1250 

1250 

0 

0 

Total 

50 

50 

81224 

81199 

25 

0.03078 

Data  Group 

N/A 

50 

78100 

78077 

23 

0.02945 

Smart  Bit  Group 

N/A 

50 

1562 

1561 

1 

0.06402 

VoIP  Group 

N/A 

50 

1562 

1561 

1 

0.06402 

Total 

60 

60 

97448 

97425 

23 

0.0236 

Data  Group 

N/A 

60 

93700 

93677 

23 

0.02455 

Smart  Bit  Group 

N/A 

60 

1874 

1874 

0 

0 

VoIP  Group 

N/A 

60 

1874 

1874 

0 

0 

Total 

70 

70 

113776 

113683 

93 

0.08174 

Data  Group 

N/A 

70 

109400 

109308 

92 

0.0841 

Smart  Bit  Group 

N/A 

70 

2188 

2187 

1 

0.0457 

VoIP  Group 

N/A 

70 

2188 

2188 

0 

0 

Total 

80 

80 

130000 

129940 

60 

0.04615 

Data  Group 

N/A 

80 

125000 

124942 

58 

0.0464 

Smart  Bit  Group 

N/A 

80 

2500 

2498 

2 

0.08 

VoIP  Group 

N/A 

80 

2500 

2500 

0 

0 

Total 

90 

90 

146224 

146143 

81 

0.05539 

Data  Group 

N/A 

90 

140600 

140525 

75 

0.05334 

Smart  Bit  Group 

N/A 

90 

2812 

2808 

4 

0.14225 

VoIP  Group 

N/A 

90 

2812 

2810 

2 

0.07112 

Total 

100 

100 

162448 

161850 

598 

0.36812 

Data  Group 

N/A 

100 

156200 

155618 

582 

0.3726 

Smart  Bit  Group 

N/A 

100 

3124 

3118 

6 

0.19206 

VoIP  Group 

N/A 

100 

3124 

3114 

10 

0.3201 

FrameSize 

1518 

Throughput  (%  max  load) 

100 

Frame  Loss  (%) 

0.36812 

Table  32.  TERABEAM  VOIP  SMART  BITS  DATA  AT  RAYTHEON 


Terabeam  was  used  to  test  the  KG-  235s.  The  KG-  235  is  a  bulk  INE  that 
is  used  to  secure  the  link  between  the  two  sites.  The  KG-235  was  placed  into  the  network 
as  described  in  the  previous  testing  at  General  Dynamics. 

e.  Crypto  (INE) 

The  placement  of  the  In-Line  Encryptor  (INE)  was  between  the  Terabeam 
link  and  the  local  area  network’s  Cisco  3550  switch.  The  Cisco  3745  routers  were 
removed  from  the  network  in  order  to  make  the  KG-235s  work  properly.  The  KG-235s 
functioned  as  routers  for  the  two  networks.  The  KG-235s  were  assigned  Internet 
Protocol  network  addresses  on  different  subnets  in  order  for  the  two  networks  to 
communicate  with  each  other.  A  CAT- 5  cable  was  used  to  connect  one  side  (one  of  two 
Ethernet  ports  on  the  KG-235)  to  the  Elliptica  from  Terabeam.  The  other  side  (second 
Ethernet  port)  of  the  KG-235  was  connected  to  the  local  area  network’s  Cisco  3550 
switch  with  CAT-5  cable.  The  laptops,  configured  on  the  same  subnet  as  the  KG-235, 
were  connected  to  the  switch. 

Two  runs  were  conducted  using  the  Iperf  test.  The  first  run  was  conducted 
with  max  window  size  set  for  the  computers  to  handle  maximum  throughput  across  the 
link.  The  data  below  represents  the  first  run  of  data. 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1  MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168.1.2  port  1072 


[ID]: 

Interval 

Transfer 

Bandwidth 

[920] 

0.0-  1.0  sec 

0.6  MBytes 

4.4  Mbits/sec 

[920] 

1.0-  2.0  sec 

0.5  MBytes 

4.0  Mbits/sec 

[920] 

2.0-  3.0  sec 

0.6  MBytes 

4.4  Mbits/sec 

[920] 

3.0-  4.0  sec 

0.5  MBytes 

4.1  Mbits/sec 

[920] 

4.0-  5.0  sec 

0.5  MBytes 

4.4  Mbits/sec 

[920] 

5.0-  6.0  sec 

0.4  MBytes 

3.4  Mbits/sec 

[920] 

6.0-  7.0  sec 

0.5  MBytes 

4.4  Mbits/sec 

[920] 

7.0-  8.0  sec 

0.5  MBytes 

3.7  Mbits/sec 

[920] 

8.0-  9.0  sec 

0.5  MBytes 

4.3  Mbits/sec 

[920] 

9.0-10.0  sec 

0.4  MBytes 

3.4  Mbits/sec 

[920] 

0.0-10.1  sec 

5.1  MBytes 

4.1  Mbits/sec 
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During  the  second  run  the  settings  on  the  INE  itself  were  maximized  to 
full  capacity  and  the  following  results  were  achieved: 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168.1.2  port  1036 


[ID]; 

Interval 

Transfer 

Bandwidth 

[920] 

0.0-  1.3  sec 

0.1  MBytes 

0.8 

Mbits/sec 

[920] 

1.3-  2.1  sec 

0.0  MBytes 

0.1 

Mbits/sec 

[920] 

2.1-  3.0  sec 

0.5  MBytes 

4.0 

Mbits/sec 

[920] 

3.0-  4.0  sec 

0.3  MBytes 

2.6 

Mbits/sec 

[920] 

4.0-  5.0  sec 

0.5  MBytes 

4.1 

Mbits/sec 

[920] 

5.0-  6.0  sec 

0.5  MBytes 

4.2 

Mbits/sec 

[920] 

6.0-  7.0  sec 

0.5  MBytes 

3.8 

Mbits/sec 

[920] 

7.0-  8.0  sec 

0.5  MBytes 

4.0 

Mbits/sec 

[920] 

8.0-  9.0  sec 

0.5  MBytes 

3.9 

Mbits/sec 

[920] 

9.0-10.0  sec 

0.5  MBytes 

3.9 

Mbits/sec 

[920] 

0.0-10.4  sec 

4.0  MBytes 

3.1 

Mbits/sec 

It  was  discovered  during  the  second  run  that  the  INE  needed  the  latest 
firmware  in  order  to  provide  a  larger  throughput  for  the  network.  This  information  was 
not  known  prior  to  the  experiment,  which  limited  a  thorough  examination  of  the  INE. 

Later  in  the  week,  another  FSO  company  named  fSONA  tested  the  link 
with  the  KG-235s.  Here  again  the  window  size  was  manipulated  in  order  to  achieve 
maximum  throughput  across  the  link.  The  maximum  throughput  obtained  using  the  KG- 
235  is  represented  below. 

Encrypted  with  KG-235 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1MByte 


[920]  local  192.168.1.25  port  5001  connected  with  192.168.3.25  port  1808 


[  ID]  Interval 

Transfer 

Bandwidth 

[920]  0.0-  1.0  sec 

0.6  Mbytes 

4.8  Mbits/sec 

[920]  1.0- 2.0  sec 

0.6  MBytes 

5.0  Mbits/sec 

[920]  2.0- 3.0  sec 

0.6  MBytes 

5.0  Mbits/sec 

[920]  3.0- 4.0  sec 

0.6  MBytes 

5.0  Mbits/sec 

[920]  4.0- 5.0  sec 

0.6  MBytes 

5.0  Mbits/sec 

[920]  5.0-  6.0  sec 

0.6  MBytes 

5.0  Mbits/sec 

[920]  6.0- 7.0  sec 

0.6  MBytes 

5.0  Mbits/sec 
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[920]  7.0- 8.0  sec 
[920]  8.0- 9.0  sec 
[920]  9.0-10.0  sec 
[920]  0.0-10.1  sec 


0.6  MBytes 
0.6  MBytes 
0.6  MBytes 
6.3  MBytes 


5.1  Mbits/sec 
4.9  Mbits/sec 
5.0  Mbits/sec 
5.0  Mbits/sec 


The  following  day  the  authors  introduced  a  new  technology  to  the  field- 
testing  site,  Radio  Frequency  Module  (RFM). 

f.  RFM 

The  RFM,  described  earlier  in  the  General  Dynamics  testing  portion  of  the 
thesis,  is  produced  by  Ceragon  Networks.  GDDS  packages  the  product  in  a  deployable 
case  with  a  Cisco  2950  switch  for  GDDS  customers.  The  hardened  case  and  microwave 
dish  is  field  expedient  to  withstand  a  rugged  military  environment.  GDDS  supported  the 
experiment  with  Jon  Seime  and  William  Dean. 

The  series  of  tests  conducted  with  the  RFM  involved  the  RFM  conducting 
an  Iperf  test,  a  data  transfer  test  monitored  by  SolarWinds,  and  a  SmartBits  test.  After 
the  RFM  was  tested,  MRV’s  Terescope  3000  (Free  Space  Optics  product)  was  tested. 
This  testing  is  described  later  in  the  thesis.  Immediately  following  the  FSO  test,  MRV’s 
OptiSwitch  was  tested.  The  MRV’s  OptiSwitch  was  used  in  combination  with  the  RFM 
and  the  FSO.  This  testing  is  described  later  in  the  thesis  as  well. 

During  the  Iperf  testing  with  the  RFM,  the  students  conducted  several  data 
runs  to  find  the  appropriately  sized  packet  that  would  maximize  throughput  for  data  file 
transfers.  The  Iperf  data  below  represents  the  maximum  throughput  data  gathered  across 
the  RFM  link. 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168. 
[  ID]  Interval  Transfer  Bandwidth 


[920] 

0.0-  1.0  sec 

11.0 

[920] 

1.0-  2.0  sec 

11.1 

[920] 

2.0-  3.0  sec 

10.6 

[920] 

3.0-  4.0  sec 

10.6 

[920] 

4.0-  5.0  sec 

10.6 

[920] 

5.0-  6.0  sec 

11.3 

MBytes  88.2  Mbits/sec 

MBytes  88.6  Mbits/sec 

MBytes  84.3  Mbits/sec 

MBytes  85.0  Mbits/sec 

MBytes  84.9  Mbits/sec 

MBytes  90.2  Mbits/sec 


1 


.2  port  1090 


88 


[920] 

6.0-  7.0  sec 

11.2 

[920] 

7.0-  8.0  sec 

11.3 

[920] 

8.0-  9.0  sec 

11.3 

[920] 

9.0-10.0  sec 

11.3 

[920] 

0.0-10.0  sec 

110 

MBytes  90.2  Mbits/sec 

MBytes  90.2  Mbits/sec 

MBytes  90.2  Mbits/sec 

MBytes  90.2  Mbits/sec 

MBytes  88.3  Mbits/sec 


The  transfer  of  data  test  monitored  by  SolarWinds  illustrated  a  maximum 
throughput  of  40  Mbps.  During  this  series  of  testing,  there  were  9  runs  completed  in  all. 
The  first  run  was  only  a  300  Mbyte  data  file  transferred  from  one  local  area  network  to 
another.  During  the  data  file  transfer,  VoIP  quality  was  monitored  by  the  clarity  of  the 
voice  conversation  while  the  transfer  was  occurring.  For  the  remainder  of  the  data  file 
transfer  test,  along  with  VoIP,  there  was  a  video  camera  transmitting  data  across  the  link. 
Additionally,  a  video  file  was  being  played  on  one  of  the  computers  that  was  transferring 
data  files  to  the  distant  end  of  the  network.  The  data  gathered  is  represented  in  the  table 
below  (Table  33). 


1  Run  No.  1  Media 

1  Size 

1  Throughput 

1  Loss  (%) 

1  VOICE  1 

1  VIDEO  1 

1  i  1 

1  Microwave 

^40^^ 

2 

Microwave 

1.5  M 

1” 

2.7M 

0 

YES 

YES 

3 

Microwave 

5M 

2" 

7.8M 

0 

YES 

YES 

4 

Microwave 

lOM 

5" 

15M 

0 

YES 

YES 

5 

Microwave 

75  M 

17” 

32M 

0 

YES 

YES 

6 

Microwave 

150  M 

00 

36M 

0 

YES 

YES 

7 

Microwave 

300  M 

170” 

33M 

0 

YES 

YES 

8 

Microwave 

600  M 

3’14” 

39M 

0 

YES 

YES 

9 

Microwave 

1.2  GIG 

6’30” 

36M 

0 

YES 

YES 

Table  33 .  RFM  SOLARWINDS  DATA  AT  RAYTHEON 


During  the  SmartBits  test,  SmartBits  simulated  20  VoIP  phone 
conversations  going  across  the  network.  Additionally,  SmartBits  simulated  100 
computers  passing  information  simultaneously  across  the  network.  The  test  revealed  a 
less  than  1  %  packet  loss  across  the  network  as  the  load  on  the  network  increased  in  10 
Mbyte  increments.  The  table  below  shows  the  information  gathered  during  this  series  of 
testing  (Table  34). 
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Total 

10 

10 

26000 

26000 

0 

0 

Data  Group 

N/A 

10 

9300 

9280 

20 

0.21505 

VoIP  Group 

N/A 

10 

13000 

13000 

0 

0 

Total 

20 

20 

39000 

39000 

0 

0 

Data  Group 

N/A 

20 

18600 

18560 

40 

0.21505 

VoIP  Group 

N/A 

20 

13000 

13000 

0 

0 

Total 

30 

30 

52000 

52000 

0 

0 

Data  Group 

N/A 

30 

27880 

27840 

40 

0.14347 

VoIP  Group 

N/A 

30 

13000 

13000 

0 

0 

Total 

40 

40 

65000 

65000 

0 

0 

Data  Group 

N/A 

40 

37160 

37120 

40 

0.10764 

VoIP  Group 

N/A 

40 

13000 

13000 

0 

0 

Total 

50 

50 

91000 

91000 

0 

0 

Data  Group 

N/A 

50 

55720 

55700 

20 

0.03589 

VoIP  Group 

N/A 

50 

13000 

13000 

0 

0 

Total 

60 

60 

104000 

104000 

0 

0 

Data  Group 

N/A 

60 

65000 

65000 

0 

0 

VoIP  Group 

N/A 

60 

13000 

13000 

0 

0 

Total 

70 

70 

117000 

117000 

0 

0 

Data  Group 

N/A 

70 

74300 

74280 

20 

0.02692 

VoIP  Group 

N/A 

70 

13000 

13000 

0 

0 

Total 

80 

80 

130000 

130000 

0 

0 

Data  Group 

N/A 

80 

83600 

83560 

40 

0.04785 

VoIP  Group 

N/A 

80 

13000 

13000 

0 

0 

Total 

90 

90 

156000 

156000 

0 

0 

Data  Group 

N/A 

90 

102160 

102120 

40 

0.03915 

VoIP  Group 

N/A 

90 

13000 

13000 

0 

0 

Total 

100 

100 

169000 

169000 

0 

0 

Data  Group 

N/A 

100 

111440 

111400 

40 

0.03589 

VoIP  Group 

N/A 

100 

13000 

13000 

0 

0 

Table  34.  RFM  SMART  BITS  DATA  AT  RAYTHEON 


As  mentioned  earlier  in  this  section,  FSO  was  tested  on  the  same  day  as 
the  RFM.  The  FSO  company  was  MRV.  Founded  in  1988,  MRV’s  corporate 
headquarters  is  in  Chatsworth,  Califomia.47 
g.  MRV 

The  personnel  that  supported  the  evolution  were  Tim  Kcehowski,  Director 
of  Federal  Sales;  Levon  Fayson,  Technical  Support  Engineering  Manager;  and  Isaac 
Kim,  Director  of  FSO.  Mr.  Fayson  diligently  set  up  and  aligned  the  Terescope  5000  OC- 


47  http :  //  archive  .mrv.  com/  corporate/profile  .php 
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3  link  heads.  The  environment  was  a  metropolitan  area  spanning  a  distance  between  sites 
of  6,700  meters.  The  weather  was  very  windy  with  partly  sunny  skies  and  a  temperature 
in  the  mid  60’s. 

The  data  collected  during  MRV’s  Terescope  test  involved  the  Iperf  test, 
the  data  transfer  test  monitored  by  SolarWinds,  and  the  SmartBits  test.  Several  runs  of 
the  Iperf  test  were  conducted.  The  reason  for  several  runs  was  that  the  soft  rooftop  on 
Raytheon’s  building,  where  the  Terescope  was  mounted,  and  people  walking  around  the 
Terescope  caused  enough  movement  to  the  scope  to  take  it  out  of  alignment.  This  will  be 
addressed  by  MRV  adding  new  advanced  tracking  into  their  FSO  system.  The  Terescope 
was  secured  with  concrete  blocks  in  order  to  stabilize  it  on  top  of  the  building.  The  Iperf 
data  below  represents  the  maximum  data  throughput  via  MRV’s  link. 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1MByte 


[920]  local  192.168.3 
[  ID]  Interval 
[920]  0.0-  I.Osec 
[920]  I.0-2.0sec 
[920]  2.0- 3.0  sec 
[920]  3.0- 4.0  sec 
[920]  4.0- 5.0  sec 
[920]  5.0-  6.0  sec 
[920]  6.0- 7.0  sec 
[920]  7.0- 8.0  sec 
[920]  8.0- 9.0  sec 
[920]  9.0-10.0  sec 
[920]  0.0-10.0  sec 


.3  port  5001  connected  with  192.168.1.2  port  1063 


Transfer 

11.1  MBytes 

11.2  MBytes 

11.2  MBytes 

11.2  MBytes 

11.3  MBytes 

11.2  MBytes 

11.1  MBytes 

11.3  MBytes 

11.2  MBytes 

1 1.3  MBytes 
112  MBytes 


Bandwidth 

88.3  Mbits/sec 

89.8  Mbits/sec 

89.9  Mbits/sec 

89.7  Mbits/sec 

89.9  Mbits/sec 

89.7  Mbits/sec 

89.9  Mbits/sec 

89.9  Mbits/sec 

89.7  Mbits/sec 
90.1  Mbits/sec 

89.7  Mbits/sec 


The  data  fde  transfer  test  monitored  by  SolarWinds  consisted  of  a  total  of 
18  runs.  The  first  series  of  runs  consisted  of  data  fdes  transferred  from  one  local  area 
network  to  another.  The  data  fdes  ranged  from  1.5  Mbytes  to  1.2  Gbytes  in  size.  The 
second  series  of  runs  consisted  of  data  file  transfers  while  VoIP  was  running  as  the  data 
files  were  transferred  from  one  local  area  network  to  another.  The  last  series  of  runs 
consisted  of  data  files  being  transferred  while  VoIP  and  video  were  running  as  the  data 
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files  were  being  transferred.  The  table  below  represents  the  data  obtained  from  the  data 
file  transfer  test  using  SolarWinds  (Table  35). 


Run  No. 

Media 

Size 

Time 

Throughput 

Loss  (%) 

VOICE 

VIDEO 

1 

FSO 

1.5  M 

1” 

2.8M 

0 

NO 

NO 

2 

FSO 

5  M 

1” 

7.92M 

0 

NO 

NO 

3 

FSO 

10  M 

2” 

15M 

0 

NO 

NO 

4 

FSO 

75  M 

15” 

50M 

0 

NO 

NO 

5 

FSO 

150  M 

33” 

46M 

0 

NO 

NO 

6 

FSO 

300  M 

1’03” 

47M 

0 

NO 

NO 

7 

FSO 

600  M 

2T2” 

50M 

0 

NO 

NO 

8 

FSO 

1.2  GIG 

4’20” 

53M 

3 

NO 

NO 

9 

FSO 

1.5  M 

1” 

6M 

0 

YES 

NO 

10 

FSO 

5  M 

1” 

8M 

0 

YES 

NO 

11 

FSO 

10  M 

2” 

15M 

0 

YES 

NO 

12 

FSO 

75  M 

16” 

59M 

0 

YES 

NO 

13 

FSO 

150  M 

32” 

50M 

0 

YES 

NO 

14 

FSO 

300  M 

59” 

50m 

0 

YES 

NO 

15 

FSO 

600  M 

2’50” 

40m 

0 

YES 

NO 

16 

FSO 

1.5  M 

1” 

6M 

0 

YES 

YES 

17 

FSO 

5  M 

1” 

8M 

0 

YES 

YES 

18 

FSO 

10  M 

2” 

15M 

0 

YES 

YES 

Table  35.  MRV’S  SOLARWINDS  DATA  AT  RAYTHEON 


The  final  test  conducted  using  only  MRV’s  link  was  a  SmartBits  test. 
SmartBits  generated  simulated  data  being  transferred  across  the  link.  The  simulated  data 
consisted  of  100  computers  passing  information  across  the  network  plus  20  simulated 
VoIP  phone  conversations  going  across  the  network.  The  table  below  is  an  excerpt  of  the 
data  obtained  from  SmartBits  (Table  36). 
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Total 

10 

10 

26000 

26000 

0 

0 

Data  Group 

N/A 

10 

13000 

13000 

0 

0 

VoIP  Group 

N/A 

10 

13000 

13000 

0 

0 

Total 

20 

20 

39000 

39000 

0 

0 

Data  Group 

N/A 

20 

26000 

26000 

0 

0 

VoIP  Group 

N/A 

20 

13000 

13000 

0 

0 

Total 

30 

30 

52000 

52000 

0 

0 

Data  Group 

N/A 

30 

39000 

39000 

0 

0 

VoIP  Group 

N/A 

30 

13000 

13000 

0 

0 

Total 

40 

40 

65000 

65000 

0 

0 

Data  Group 

N/A 

40 

52000 

52000 

0 

0 

VoIP  Group 

N/A 

40 

13000 

13000 

0 

0 

Total 

50 

50 

91000 

91000 

0 

0 

Data  Group 

N/A 

50 

78000 

78000 

0 

0 

VoIP  Group 

N/A 

50 

13000 

13000 

0 

0 

Total 

60 

60 

104000 

104000 

0 

0 

Data  Group 

N/A 

60 

91000 

91000 

0 

0 

VoIP  Group 

N/A 

60 

13000 

13000 

0 

0 

Total 

70 

70 

117000 

117000 

0 

0 

Data  Group 

N/A 

70 

104000 

104000 

0 

0 

VoIP  Group 

N/A 

70 

13000 

13000 

0 

0 

Total 

80 

80 

130000 

130000 

0 

0 

Data  Group 

N/A 

80 

117000 

117000 

0 

0 

VoIP  Group 

N/A 

80 

13000 

13000 

0 

0 

Total 

90 

90 

156000 

156000 

0 

0 

Data  Group 

N/A 

90 

143000 

143000 

0 

0 

VoIP  Group 

N/A 

90 

13000 

13000 

0 

0 

Total 

100 

100 

169000 

169000 

0 

0 

Data  Group 

N/A 

100 

156000 

156000 

0 

0 

VoIP  Group 

N/A 

100 

13000 

13000 

0 

0 

Table  36.  MRV’S  SMART  BITS  DATA  AT  RAYTHEON 


The  exciting  portion  of  this  day’s  testing  was  when  both  technologies 
(FSO  and  RFM)  were  integrated.  Only  MRV’s  Terescope  5000  made  this  combination 
possible.  The  product  and  its  capabilities  are  explained  in  the  next  section  of  testing. 
h.  MRV-RFM  Switchover 

The  RFM  was  connected  to  the  MRV  manufactured  media  converter. 
This  converted  the  CAT  5  Ethernet  from  the  RFM  to  fiber  to  feed  the  Terescope  5000 
scope.  The  Terescope  5000  has  two  optical  connections:  one  is  for  the  direct  fiber  feed 
and  the  other  is  the  standby  to  another  fiber  or  RF  backup  system.  With  the  MRV  patent 
Fusion  feature,  the  auto  switching  from  the  FSO  to  RFM  took  place  within  2 
milliseconds.  Therefore,  there  was  little  to  no  impact  in  the  traffic  being  transmitted.  The 
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Terescope  5000  Fusion  is  a  bit  different  than  the  Terescope  3000  unit  in  that  the  auto 
switch  over  from  the  FSO  to  the  RFM  was  done  internally  in  the  Terescope  5000  scope. 
There  was  no  external  switch  required  for  this  action,  which  really  simplified  the 
installation.  The  figure  below  shows  an  illustration  of  the  Terescope  5000  with  the  built- 
in  OptiSwitch  feature  (Figure  42). 


Figure  43.  MRV’S  TERESCOPE  5000  WITH  BUILT-IN  OPTISWITCH 

During  the  switchover  portion  of  the  experiment,  MRV’s  Terescope  was 
covered  so  that  the  RFM  could  pick  up  the  link  between  local  area  networks.  Simulated 
computer  and  VoIP  data  was  being  sent  across  the  network  via  SmartBits.  The  laser  was 
covered  while  SmartsBits  was  running.  This  process  forced  the  RFM  to  pick  up  the  link 
via  the  OptiSwitch.  The  table  below  is  an  excerpt  of  the  SmartBits  data  collected  while 
this  experiment  was  in  progress  (Table  37).  The  packet  loss  was  recorded  at  50  percent 
due  to  the  change  between  the  FSO  link  and  RFM. 
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T  otal 

10 

10 

24000 

12000 

12000 

50 

Data  Group 

N/A 

10 

16000 

8000 

8000 

50 

VoIP  Group 

N/A 

10 

8000 

4000 

4000 

50 

Total 

20 

20 

40000 

20000 

20000 

50 

Data  Group 

N/A 

20 

32000 

16000 

16000 

50 

VoIP  Group 

N/A 

20 

8000 

4000 

4000 

50 

T  otal 

30 

30 

56000 

28000 

28000 

50 

Data  Group 

N/A 

30 

48000 

24000 

24000 

50 

VoIP  Group 

N/A 

30 

8000 

4000 

4000 

50 

Total 

40 

40 

72000 

36000 

36000 

50 

Data  Group 

N/A 

40 

64000 

32000 

32000 

50 

VoIP  Group 

N/A 

40 

8000 

4000 

4000 

50 

T  otal 

50 

50 

88000 

44000 

44000 

50 

Data  Group 

N/A 

50 

80000 

40000 

40000 

50 

VoIP  Group 

N/A 

50 

8000 

4000 

4000 

50 

Total 

60 

60 

104000 

52000 

52000 

50 

Data  Group 

N/A 

60 

96000 

48000 

48000 

50 

VoIP  Group 

N/A 

60 

8000 

4000 

4000 

50 

T  otal 

70 

70 

120000 

60000 

60000 

50 

Data  Group 

N/A 

70 

112000 

56000 

56000 

50 

VoIP  Group 

N/A 

70 

8000 

4000 

4000 

50 

Total 

80 

80 

136000 

68000 

68000 

50 

Data  Group 

N/A 

80 

128000 

64000 

64000 

50 

VoIP  Group 

N/A 

80 

8000 

4000 

4000 

50 

T  otal 

90 

90 

152000 

76000 

76000 

50 

Data  Group 

N/A 

90 

144000 

72000 

72000 

50 

VoIP  Group 

N/A 

90 

8000 

4000 

4000 

50 

Total 

100 

100 

168000 

84000 

84000 

50 

Data  Group 

N/A 

100 

160000 

80000 

80000 

50 

VoIP  Group 

N/A 

100 

8000 

4000 

4000 

50 

Table  37.  MRV’S  OPTISWITCH  SMART  BITS  DATA  AT  RAYTHEON 


During  the  Smart  Bits  test,  SolarWinds  recorded  a  54  Mbps  throughput 
when  the  data  was  going  across  the  FSO  link  and  a  33  Mbps  throughput  when  the  data 
was  going  across  the  RFM  link.  Throughout  the  SmartBits  testing,  SolarWinds  did  not 
drop  the  link  (the  term  “not  drop  the  link”  indicated  that  the  link  remained  operational 
while  the  switchover  occurred  between  media  links). 

The  last  day  of  testing  was  very  exciting;  a  new  technology  was 
introduced  to  the  authors  of  this  thesis.  The  new  technology  was  Orthogonal  Frequency 
Division  Multiplexing  (OFDM).  Alvarion  demonstrated  their  OFDM  product,  which  has 
BLOS  capability.  Alvarion’s  OFDM  product  is  explained  in  the  BLOS  section  of  the 
Raytheon  testing.  Also  on  the  last  day  of  testing,  the  Iridium  Inverse  Multiplexer 
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(IMUX)  was  tested.  The  IMUX  test  can  be  found  in  the  OTH  section  of  the  Raytheon 
testing.  Another  FSO  company,  fSONA,  was  tested  at  the  6.7  kilometer  range. 

L  fSONA 

The  company,  fSONA,  brought  the  same  product,  SONAbeam  155-M,  as 
the  previous  testing  evolutions.  The  personnel  that  fSONA  sent  to  support  the 
experiments  were  Mike  Corcoran,  Senior  Vice  President  of  Sales  and  Marketing;  Kelly 
Irvin,  Director  Western  Sales;  Pablo  Bandera,  fSONA’ s  Product  Manager;  and  Sean 
Dante,  Field  Technician.  The  equipment  took  roughly  45  minutes  to  set  up  and  align. 
The  series  of  testing  included  an  Iperf  data  test,  a  data  file  transfer  test  monitored  by 
SolarWinds,  and  a  Smart  Bits  test. 

The  Iperf  test  consisted  of  nine  data  runs.  Six  of  the  data  runs  were 
conducted  with  fSONA’s  equipment  uncovered  (without  any  crypto,  KG-235).  The 
window  size  was  manipulated  in  order  to  obtain  the  maximum  throughput  for  the  link 
being  tested.  Then,  three  data  runs  were  conducted  using  the  KG-235s  for  bulk 
encryption  (results  were  discussed  earlier  in  this  thesis).  The  maximum  throughput 
obtained  without  using  the  KG-235  is  represented  below. 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1  MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168.1.2  port  1038 

[  ID]  Interval  Transfer  Bandwidth 

[920]  0.0- 1.0  sec  10.9  MBytes  87.1  Mbits/sec 

[920]  1.0- 2.0  sec  11.0  MBytes  88.1  Mbits/sec 

[920]  2.0- 3.0  sec  11.3  MBytes  90.2  Mbits/sec 

[920]  3.0- 4.0  sec  11.3  Mbytes  90.1  Mbits/sec 

[920]  4.0- 5.0  sec  10.8  Mbytes  86.1  Mbits/sec 

[920]  5.0- 6.0  sec  11.3  Mbytes  90.1  Mbits/sec 

[920]  6.0- 7.0  sec  11.1  Mbytes  89.2  Mbits/sec 

[920]  7.0- 8.0  sec  11.3  Mbytes  90.1  Mbits/sec 

[920]  8.0- 9.0  sec  11.3  Mbytes  90.1  Mbits/sec 

[920]  9.0-10.0  sec  11.3  MBytes  90.1  Mbits/sec 

[920]  0.0-10.0  sec  112  MBytes  89.2  Mbits/sec 


The  data  transfer  test  monitored  by  SolarWinds  consisted  of  16  runs  of 
data  transfer.  The  first  series  of  data  transfer  was  conducted  while  VoIP  was  being  used 


96 


across  the  link.  The  second  series  of  data  transfer  was  conducted  while  VoIP  was  being 
used  and  a  video  camera  also  streamed  video  across  the  link.  Additionally,  each 


1  Run  No. 

Media 

Size 

Time 

1  Throughput 

Loss  (%) 

1  VOICE  1 

1  VIDEO 

1 

FSO 

1.5  M 

I" 

3.43M 

0 

YES 

NO 

2 

FSO 

5  M 

I" 

7.96M 

0 

YES 

NO 

3 

FSO 

10  M 

2" 

I5M 

0 

YES 

NO 

4 

FSO 

75  M 

15" 

53M 

0 

YES 

NO 

5 

FSO 

150  M 

30" 

50M 

0 

YES 

NO 

6 

FSO 

300  M 

I ’00" 

45M 

0 

YES 

NO 

7 

FSO 

600  M 

2'10" 

50M 

0 

YES 

NO 

8 

FSO 

1.2  GIG 

4'26" 

45M 

0 

YES 

NO 

9 

FSO 

1.5  M 

I" 

2.9IM 

0 

YES 

YES 

10 

FSO 

5  M 

I" 

8M 

0 

YES 

YES 

11 

FSO 

10  M 

2" 

I6M 

0 

YES 

YES 

12 

FSO 

75  M 

12" 

45M 

0 

YES 

YES 

13 

FSO 

150  M 

30" 

52M 

0 

YES 

YES 

14 

FSO 

300  M 

52" 

52M 

0 

YES 

YES 

15 

FSO 

600  M 

2'20" 

50M 

0 

YES 

YES 

16 

FSO 

1.2  GIG 

5T5" 

36M 

0 

YES 

YES 

computer  was  running  video  on  the  computer  as  the  test  was  being  conducted. 


he  table 


below  indicates  the  data  obtained  while  this  test  was  conducted  (Table  38). 


Table  38.  fSONA  SOLARWINDS  DATA  AT  RAYTHEON 


The  next  series  of  tests  were  conducted  using  SmartBits.  During  this 
series  of  testing,  SmartBits  simulated  100  computers  passing  data  across  the  two 
networks  and  24  simulated  phone  conversations  passing  information  across  the  network. 
Out  of  all  the  technologies  tested,  fSONA  had  the  lowest  frame  loss  percentage.  The 
frame  loss  percentage  was  .00118  %.  This  low  frame  loss  percentage  may  be  a  result  of 
fSONA’ s  lasers  being  able  to  produce  a  power  output  of  640  milliwatts,  a  considerable 
difference  over  all  other  companies.  The  network  was  stressed  by  applying  data  in  10 
Mbyte  increments  until  the  network  was  passing  100  Mbytes  of  data.  The  table  below  is 
an  excerpt  of  the  data  obtained  by  SolarWinds  (Table  39). 
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Total 

10 

10 

26000 

26000 

0 

0 

Data  Group 

N/A 

10 

13000 

13000 

0 

0 

VoIP  Group 

N/A 

10 

13000 

13000 

0 

0 

Total 

20 

20 

39000 

39000 

0 

0 

Data  Group 

N/A 

20 

26000 

26000 

0 

0 

VoIP  Group 

N/A 

20 

13000 

13000 

0 

0 

Total 

30 

30 

52000 

52000 

0 

0 

Data  Group 

N/A 

30 

39000 

39000 

0 

0 

VoIP  Group 

N/A 

30 

13000 

13000 

0 

0 

Total 

40 

40 

65000 

65000 

0 

0 

Data  Group 

N/A 

40 

52000 

52000 

0 

0 

VoIP  Group 

N/A 

40 

13000 

13000 

0 

0 

Total 

50 

50 

91000 

91000 

0 

0 

Data  Group 

N/A 

50 

78000 

78000 

0 

0 

VoIP  Group 

N/A 

50 

13000 

13000 

0 

0 

Total 

60 

60 

104000 

104000 

0 

0 

Data  Group 

N/A 

60 

91000 

91000 

0 

0 

VoIP  Group 

N/A 

60 

13000 

13000 

0 

0 

Total 

70 

70 

117000 

117000 

0 

0 

Data  Group 

N/A 

70 

104000 

104000 

0 

0 

VoIP  Group 

N/A 

70 

13000 

13000 

0 

0 

Total 

80 

80 

130000 

130000 

0 

0 

Data  Group 

N/A 

80 

117000 

117000 

0 

0 

VoIP  Group 

N/A 

80 

13000 

13000 

0 

0 

Total 

90 

90 

156000 

156000 

0 

0 

Data  Group 

N/A 

90 

143000 

143000 

0 

0 

VoIP  Group 

N/A 

90 

13000 

13000 

0 

0 

Total 

100 

100 

169000 

168998 

2 

0.00118 

Data  Group 

N/A 

100 

156000 

155998 

2 

0.00128 

VoIP  Group 

N/A 

100 

13000 

13000 

0 

0 

fable  39. 

fSONA’S  SMARTS] 

[TS  DATA  AT  ] 

RAYTHEON 

The  technologies  used  in  the  line-of-sight  testing  showed  potential  to  be 
implemented  in  both  a  UOC  and  CAC2S  architecture.  A  key  tool  used  in  determining  the 
quality  of  the  link  across  the  network  is  the  VoIP.  The  next  section  will  briefly  discuss 
VoIP. 

j.  Voice  Over  Internet  Protocol  (VoIP) 

LT  Manny  Cordero  has  been  studying  VoIP  at  NPS.  LT  Cordero’s  thesis 
involves  VoIP  and  his  contributions  in  providing  a  mixture  of  equipment  and  expertise 
was  key  to  this  thesis  research. 

The  IP  telephones  used  were  the  Cisco  7960G.  The  telephones  were 
connected  to  the  network  via  CAT-5  cable  to  the  Cisco  switch.  Present  at  the  MRF  was 
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the  Call  Manager  server  that  managed  the  IP  phones  in  the  network.  The  server  assigned 
each  phone  its  own  IP  address,  which  enabled  any  phone  within  the  network  to  place  a 
call  to  any  other  phone  in  the  network. 


In  the  following  sections  VoIP  was  utilized  with  a  BLOS  company  called 
Alvarion.  While  conducting  the  data  transfer  test,  SolarWinds  would  indicate  the  link 
being  down.  However,  the  VoIP  phone  call  was  still  operating  across  the  link.  The  next 
section  will  discuss  a  Beyond  line  of  Sight  (BLOS)  technology  by  Alvarion. 

1.  Beyond  Line-of-Sight  (BLOS) 

Alvarion  from  Carlsbad,  California,  introduced  a  product  that  operated  in  a  non- 
line-of-sight  (NLOS)  mode.  Since  the  product  operates  in  a  NLOS  mode,  the  BLOS 
problem  was  tested  at  a  distance  of  6,700  meters  in  order  to  demonstrate  the  capability. 

a.  Alvarion 

The  Alvarion  personnel  who  supported  this  evolution  were  Director  of 
Strategic  Marketing,  Jasper  Bruinzeel,  and  field  technicians  Willie  Alayza  and  Soria 
Constantino.  The  product  introduced  to  the  testing  was  Alvarion’ s  BreezeACCESS  VL 
system.  The  system  is  a  point-to-multi-point  or  point-to-point  system.  The  system 
operates  in  the  5  GHz  frequency  band  (5.725-5.850  GHz).  The  BreezeACCESS  uses 
OFDM  technology  in  order  to  overcome  the  BLOS  problem.  The  product  can  operate  in 
speeds  of  6  Mbps,  24  Mbps,  and  54  Mbps.  The  product  used  had  an  antenna  and  radio 
built  into  one  unit.  There  are  different  versions  of  this  product,  so  the  antennas  come  in 
different  sector  types.  The  antennas  can  be  directional  or  omni-directional.  The  type  of 
equipment  is  determined  by  the  application  requirement  the  equipment  needs  to  address. 

The  testing  data  obtained  resulted  from  an  Iperf  test  and  a  SmartBits  test. 
The  Iperf  test  was  conducted  with  and  without  the  KG-235.  Several  runs  were  conducted 
in  order  to  maximize  the  throughput  across  the  link.  In  addition  to  adjusting  the  window 
size,  the  antenna  was  changed.  The  Iperf  test  started  with  a  SU-VL  integrated  antenna 
with  a  lO-degree  beam  width  and  a  21  dB  gain  on  the  BreezeACCESS.  While  the  Iperf 
test  was  being  conducted,  a  VoIP  call  was  made  along  with  streaming  video.  There  were 
three  runs  conducted  with  the  SU-VL  antenna.  The  maximum  throughput  results  from 
the  small  antenna  are  indicated  below. 
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Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1  MByte 


[920]  loeal  192.168.3.3  port  5001  eonnected  with  192.168.1.2  port  1045 

[  ID]  Interval  Transfer  Bandwidth 

[920]  0.0- 1.3  see  0.2  MBytes  1.3Mbits/see 

[920]  1.3- 2.2  see  0.2  MBytes  1.6Mbits/see 

[920]  2.2-  3.5  see  0.3  MBytes  1.6  Mbits/see 

[920]  3.5- 4.1  see  0.3  MBytes  4.2  Mbits/see 

[920]  4.1- 5.1  see  0.2  MBytes  1.7  Mbits/see 

[920]  5.1- 6.1  see  0.3  MBytes  2.7  Mbits/see 

[920]  6.1- 7.1  see  0.5  MBytes  3.9  Mbits/see 

[920]  7.1- 8.0  see  0.4  MBytes  4.1  Mbits/see 

[920]  8.0-  9.0  see  0.9  MBytes  6.9  Mbits/see 

[920]  9.0-10.0  sec  0.4  MBytes  3.0  Mbits/see 

[920]  0.0-10.3  sec  3.8  MBytes  2.9  Mbits/see 


A  larger  antenna,  a  two-foot  Uni-directional  antenna  with  a  28.5  dB  gain 
and  3  dB  beamwidth  of  4.5  degrees,  was  attached  to  the  BreezeACCESS.  Two  runs  were 
conducted  with  the  Uni-directional  antenna  while  the  streaming  video  camera  and  VoIP 
were  operational  in  the  background.  The  data  below  represents  the  maximum  throughput 
data  obtained  from  these  runs. 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168.1.2  port  1050 

[  ID]  Interval  Transfer  Bandwidth 

[920]  0.0- 1.9  sec  0.0  MBytes  0.1  Mbits/see 

[920]  1.9- 2.0  sec  0.2  MBytes  9.0  Mbits/see 

[920]  2.0- 3.1  sec  0.7  MBytes  5.2  Mbits/see 

[920]  3.1- 4.1  sec  0.7  MBytes  5.4  Mbits/see 

[920]  4.1- 5.0  sec  0.4  MBytes  3.3  Mbits/see 

[920]  5.0-  6.5  sec  0.5  MBytes  2.4  Mbits/see 

[920]  6.5- 7.0  sec  0.5  MBytes  9.1  Mbits/see 

[920]  7.0-  8.0  sec  0.5  MBytes  3.6  Mbits/see 

[920]  8.0-  9.3  sec  0.5  MBytes  2.8  Mbits/see 

[920]  9.3-10.2  sec  0.3  MBytes  2.5  Mbits/see 

[920]  0.0-10.2  sec  4.1  MBytes  3.2  Mbits/see 
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The  KG-235  was  placed  between  the  BreezeACCESS  equipment  and  the 
Cisco  router.  There  were  several  runs  conducted  with  the  window  size  changed  on  each 
run.  While  the  Iperf  data  tests  were  running,  VoIP  and  streaming  video  was  running  in 
the  background.  The  following  Iperf  data  represents  the  maximum  throughput  data 
obtained  with  the  KG-235s  in  the  network. 


Server  listening  on  TCP  port  5001 
TCP  window  size:  O.I  MByte 


[920]  local  192.168.1.25 

port  5001  connected  with  192.168.3.25  port  1811 

[  ID]  Interval 

Transfer 

Bandwidth 

[920]  0.0-  1.0  sec 

0.3  MBytes 

2.7  Mbits/sec 

[920]  1.0- 2.1  sec 

0.2  MBytes 

1.8  Mbits/sec 

[920]  2.1- 3.3  sec 

0.4  MBytes 

2.3  Mbits/sec 

[920]  3.3- 4.0  sec 

0.3  MBytes 

3.1  Mbits/sec 

[920]  4.0- 5.2  sec 

0.2  MBytes 

1.6  Mbits/sec 

[920]  5.2- 6.1  sec 

0.2  MBytes 

1 .9  Mbits/sec 

[920]  6.1- 7.0  sec 

0.3  MBytes 

2.5  Mbits/sec 

[920]  7.0- 8.0  sec 

0.4  MBytes 

2.9  Mbits/sec 

[920]  8.0- 9.0  sec 

0.3  MBytes 

2.6  Mbits/sec 

[920]  9.0-10.0  sec 

0.3  MBytes 

2.7  Mbits/sec 

[920]  0.0-10.1  sec 

3.0  MBytes 

2.4  Mbits/sec 

The  final  test  conducted  with  Alvarion  was  the  SmartBits  test.  During  the 
SmartBits  test,  100  computers  were  simulated  passing  data  across  the  network  with  data 
increments  of  10  Mbytes  until  a  maximum  throughput  of  30  Mbytes  was  reached.  The 
table  below  represents  an  excerpt  of  the  data  obtained  while  conducting  the  SmartBits 
test  (Table  40). 
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Total 

5 

5 

8126 

8126 

0 

0 

Data  Group 

N/A 

5 

8126 

8126 

0 

0 

Total 

10 

10 

16254 

16253 

1 

0.00615 

Data  Group 

N/A 

10 

16254 

16253 

1 

0.00615 

Total 

15 

15 

24382 

18840 

5542 

22.7299 

Data  Group 

N/A 

15 

24382 

18840 

5542 

22.7299 

Total 

20 

20 

32508 

20813 

11695 

35.9758 

Data  Group 

N/A 

20 

32508 

20813 

11695 

35.9758 

Total 

25 

25 

40636 

20709 

19927 

49.0378 

Data  Group 

N/A 

25 

40636 

20709 

19927 

49.0378 

Total 

30 

30 

48764 

20600 

28164 

57.7557 

Data  Group 

N/A 

30 

48764 

20600 

28164 

57.7557 

Table  40.  ALVARION’S  SMARTBITS  DATA  AT  RAYTHEON 


Figure  43  indicates  a  frame  size  of  1,518  Kbytes  and  a  throughput  of  30 
Mbps  on  the  left  and  a  frame  loss  of  57.8%  on  the  right.  The  reason  for  the  large  frame 
loss  is  that  the  throughput  oversaturated  the  link  and  packets  were  lost  during  this  state  of 
exchange  between  the  sites. 
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Throughput  vs  Frams  Sizs 

Figure  44.  ALVARION’S  SMARTBITS  GRAPH  AT  RAYTHEON 

The  final  experiment  conducted  at  Raytheon  was  the  Iridium  Inverse 
Multiplexer.  This  technology  provided  OTH  connectivity  and  is  explained  in  the 
following  section. 

2.  Over-the-Horizon  (OTH) 
a.  IMUX 

The  IMUX,  as  described  in  earlier  testing,  is  a  product  that  gives  the 
warfighter  OTH  capability  on  the  battlefield.  As  described  in  the  General  Dynamics 
testing  earlier  in  this  thesis,  Dr.  Glenn  Abousleman  utilized  his  compression  algorithm 
over  the  limited  throughput  Iridium  satellite  architecture.  The  data  obtained  from  the 
IMUX  was  the  Iperf  test  data.  Carey  Foushee,  General  Dynamics  Decision  Systems 
field  engineer,  was  the  engineer  who  made  the  IMUX  operational.  Several  data  runs 
were  conducted  with  the  IMUX.  The  excerpt  below  is  an  example  of  the  Iperf  data 
collected  from  the  test. 
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Server  listening  on  TCP  port  5001 
TCP  window  size:  62.7  KByte 


[920]  local  192.168.3.3 

port  5001  connected  with  192.168.1.2  port  1050 

[  ID]  Interval 

Transfer 

Bandwidth 

[920]  0.0- 3.0  sec 

1.9  KBytes 

5.2  Kbits/sec 

[920]  3.0- 5.5  sec 

1.9  KBytes 

6.1  Kbits/sec 

[920]  5.5- 7.8  sec 

3.4  KBytes 

11.7  Kbits/sec 

[920]  7.8- 9.0  sec 

1.0  KBytes 

6.5  Kbits/sec 

[920]  9.0-10.1  sec 

4.3  KBytes 

31.1  Kbits/sec 

[920]  10.1-11.5  sec 

4.3  KBytes 

24.1  Kbits/sec 

[920]  11.5-12.1  sec 

0.5  KBytes 

6.9  Kbits/sec 

[920]  12.1-14.3  sec 

3.4  KBytes 

12.5  Kbits/sec 

[920]  14.3-16.7  sec 

1.9  KBytes 

6.2  Kbits/sec 

[920]  16.7-18.8  sec 

1.2  KBytes 

4.6  Kbits/sec 

[920]  18.8-20.5  sec 

0.5  KBytes 

2.3  Kbits/sec 

[920]  20.5-21.3  sec 

0.7  KBytes 

7.2  Kbits/sec 

[920]  2 1.3-25.7  sec 

1.7  KBytes 

3.1  Kbits/sec 

[920]  25.7-27.9  sec 

1.2  KBytes 

4.4  Kbits/sec 

[920]  27.9-30.2  sec 

1.2  KBytes 

4.2  Kbits/sec 

[920]  30.2-32.6  sec 

1.2  KBytes 

4.0  Kbits/sec 

[920]  32.6-36.9  sec 

1.7  KBytes 

3.1  Kbits/sec 

[920]  36.9-38.7  sec 

0.5  KBytes 

2.2  Kbits/sec 

[920]  38.7-39.1  sec 

0.7  KBytes 

12.8  Kbits/sec 

[920]  39.1-41.4  sec 

1.2  KBytes 

4.2  Kbits/sec 

The  testing  interval  was  extended  up  to  1 12  seconds  for  each  of  these  runs. 
The  average  throughput  observed  was  9.6  Kbps  during  the  runs.  The  compression 
algorithm  observed  in  the  Mobile  Research  Facility  showed  that  a  several  Mbyte  picture 
was  compressed  and  sent  over  the  Iridium  link  within  seconds.  This  would  have  taken 
close  to  an  hour  without  the  compression  algorithm  applied. 

The  following  section  will  discuss  the  KG-235  In-Line  Network  Encryptor 
(INE).  The  INE  was  used  with  the  IMUX  and  the  results  were  on  average  9.6  Kbps  of 
throughput  across  the  link.  Additionally,  the  KG-235  bulk  encryption  was  tested 
throughout  the  experiment  with  different  technologies. 

b.  Crypto  (INE) 

GDDS  provided  two  KG-235  Sectera  INE  and  field  engineer,  Carey 
Foushee  made  them  operational.  The  manufacturer  of  this  product  is  GDDS.  The 
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purpose  of  utilizing  these  devices  was  to  secure  the  link  between  the  two  local  area 
networks  and  to  observe  any  noticeable  difference  in  the  throughput  while  applying 
encryption.  When  using  the  INE  with  the  IMUX,  9.6  Kbps  was  observed  as  an  average 
throughput.  Throughout  the  week,  Mr.  Foushee  diligently  established  the  link  between 
the  two  networks.  The  line  of  sight  companies  tested  with  the  INE  were  Terabeam  and 
fSONA.  Their  results  were  discussed  earlier  in  this  thesis.  The  results  from  the  BEOS 
company  tested,  Alvarion,  can  be  found  in  the  Alvarion  section  of  this  thesis. 

The  testing  at  Raytheon  proved  to  be  interesting  and  educational.  In 
March,  a  combination  of  all  these  technologies  was  integrated  at  Camp  Roberts, 
California. 

D.  FIELD  TEST  #4  (CAMP  ROBERTS) 

From  March  7-11,  2004  at  Camp  Roberts,  CA,  seven  NFS  students,  four  Marines 
from  Marine  Air  Support  Squadron  6  out  of  Miramar  Air  Station,  and  several  vendors 
participated  in  communications  testing  which  emulated  a  Marine  Corps  tactical 
environment.  The  student  participants  from  NFS  were  Captain  Gilbert  Garcia,  Captain 
David  Joseforsky,  LT  Manny  Cordero,  LT  Albert  Seeman,  LT  Ryan  Blazevich  (USN), 
Captain  Ray  Munoz  (USMC),  and  Captain  Rob  Guice  (USMC). 

Line-of-sight  (LOS),  beyond-line-of-sight  (BEOS),  and  over-the-horizon  (OTH) 
communications  were  set  up  and  tested  while  at  Camp  Roberts  for  the  following 
scenarios:  Command  and  Control  On-the-Move  Network  Digital  Over-the-Horizon 
Relay  (CoNDOR),  communications  on-the-move,  and  airborne  relay.  First,  the 
CoNDOR  scenario  was  set  up  with  two  remote  sites  located  within  LOS  of  a  Point  of 
Presence  (POP)  site.  This  occurred  with  FSO  equipment  provided  by  Lightpointe  and 
Terabeam.  In  addition,  the  two  sites  were  moved  BEOS  from  the  POP  in  order  to  use  an 
Orthogonal  Frequency  Division  Multiplexing  (OFDM)  product  provided  by  Alvarion  and 
Redline  Communications.  The  remote  sites  to  the  POP  simulated  a  company-battalion 
relationship.  The  POP  site  was  furnished  with  a  high  throughput  satellite  link  that 
communicated  back  to  the  Network  Operations  Center  (NOC),  which  resembled  a 
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battalion-regiment  relationship.  Segovia  provided  the  satellite  service  and  the  satellite 
dishes  were  furnished  by  Omega  Systems. 

Second,  two  vehicles,  Mobile  Radio  Component  (MRC)  #1  and  MRC  #2, 
simulated  a  convoy  driving  through  the  training  area  which  formulated  the 
communications  on-the-move  setup.  This  was  done  with  the  vehicles  BLOS  of  each 
other,  so  they  communicated  via  OFDM  equipment  from  Alvarion  and  Redline 
Communications.  One  vehicle  in  the  convoy,  MRC  #1,  also  had  an  INMARSAT  satellite 
link  on  the  final  day  of  the  exercise,  which  was  operated  separate  from  the  established 
network.  An  802.1  lb  link  was  established  between  the  lead  convoy  vehicle  and  the  POP 
site  via  a  tethered  balloon.  This  enabled  all  vehicles  in  that  convoy  to  communicate  with 
the  POP  site.  In  addition,  each  vehicle  in  the  convoy  had  its  own  wireless  LAN  via  an 
802. 1  la  Access  Point. 

Lastly,  the  authors  employed  a  tethered  balloon  and  Unmanned  Aerial  Vehicle 
(UAV)  over  the  training  area  as  a  means  to  extend  the  network.  They  did  this  by 
employing  802.1  lb  omni-directional  antennas  at  each  site:  MRC  #1,  POP,  NOC,  and  on 
the  airborne  platforms.  The  tethered  balloon  retransmitted  802.11b  signals  between  the 
lead  vehicle  in  the  convoy  and  the  POP  site.  MLB  Company’s  UAV  platform  was 
employed  as  an  airborne  relay  as  well,  but  it  was  not  employed  within  the  network. 

The  original  intent  was  to  use  the  Cisco  Mobile  Access  Router  (MAR),  a  hand 
sized  router  made  up  of  a  stack  of  different  cards,  at  each  of  the  ground  nodes  as  a  device 
that  could  accept  multiple  technologies  at  the  same  time  from  multiple  sites.  For 
example,  if  at  the  POP  three  different  types  of  technologies  were  coming  in  and  a  LAN 
was  required,  then  four  Ethernet  ports  that  were  layer  3  capable  would  be  needed.  Since 
the  regular  Cisco  routers  available  for  this  testing  event  only  had  two  layer  3  Ethernet 
ports  available  on  each  device,  one  router  could  not  accomplish  the  task.  In  addition,  the 
students  intended  to  test  the  MARs  in  the  airborne  platforms  by  cormecting  two  different 
types  of  technologies  to  the  MAR  at  the  same  time.  If  the  MAR  sensed  that  the  primary 
means  of  transmission  degraded,  then  it  would  automatically  switch  to  the  secondary 
means.  Figure  44  below  shows  the  MAR. 
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Figure  45.  MOBILE  ACCESS  ROUTER48 


Unfortunately,  after  days  of  working  on  the  MAR’s  configurations,  the  students 
and  the  commercial  company  on-hand  to  assist,  Western  DataCom,  could  not  get  these 
devices  to  function  properly.  Since  the  MARs  were  not  operational,  the  students  decided 
to  use  the  Cisco  3745  and  2600  series  routers  in  a  variety  of  ways:  connecting  two 
routers  together,  inserting  a  switch  between  the  routers,  and  utilizing  the  Cisco  3550 
Switch  as  a  layer  3  device  to  route. 

In  order  to  bring  all  the  above  scenarios  together  by  the  end  of  the  week,  the 
students  conducted  the  testing  in  a  step-by-step  fashion  where  each  scenario  was  tested 
individually.  On  8  March,  three  nodes  were  used:  NOC,  POP,  and  MRC  #1.  The  NOC 
and  POP  were  separated  by  about  2  kilometers  and  a  hill.  Thus,  the  two  sites  maintained 
communication  via  an  OFDM  link  in  non-line-of-sight  mode.  At  the  POP,  a  Cisco  2950 
Switch  was  placed  between  the  two  Cisco  routers  in  order  to  facilitate  OFDM  and  FSO 
links,  as  well  as  a  LAN.  This  was  done  because  each  router  had  only  two  Ethernet  ports 
that  were  layer  3  capable,  and  the  switch  was  a  layer  2  device.  Next,  the  students 
established  a  LOS  situation  between  the  POP  and  MRC  #1  at  about  1,000  meters.  The 
connectivity  between  the  two  sites  was  established  with  an  FSO  link.  Finally,  in  order  to 
facilitate  coordination  between  all  sites,  single-channel  voice  communications  were 
attained  via  VHF  and  HF  manpack  radios.  The  VHF  net  was  on  a  PRC- 119  radio  that 
was  remoted  into  the  LAN  area  with  an  A/N  GRA-39.  The  NOC  was  equipped  with  an 
OE-254  long  range  VHF  antenna,  while  the  other  two  sites  used  10-foot  whip  antennas. 
In  addition  to  the  VHF  net,  an  A/N  PRC- 104  provided  redundant  communications  on  an 
HF  net.  Figure  45  below  illustrates  the  setup. 


48  http://www.cisco.com/en/US/products/hw/routers/ps272  (May  2004). 
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Figure  46.  8  MARCH  COMMUNICATIONS  ARCHITECTURE 


On  9  March,  several  additions  and  changes  were  made  to  the  communications 
architecture.  First,  MRC  site  #2  was  added  in  order  to  facilitate  two  nodes 
communicating  with  the  POP  site.  MRC  #1  was  LOS  with  the  POP  using  an  FSO  link  at 
about  1,000  meters,  and  MRC  #2  was  BEOS  with  the  POP  using  OFDM  technology  also 
at  about  1,000  meters.  The  POP  was  now  connected  with  the  NOC  via  a  broadband 
satellite  link. 

At  the  POP  site,  a  Cisco  3550  Switch  replaced  the  router-switch  combination. 
This  facilitated  one  device  being  able  to  handle  three  different  technologies  at  the  same 
time,  such  as  FSO,  OFDM,  and  broadband  satellite,  and  also  a  LAN.  The  3550  Switch  is 
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a  Layer  2/3  capable  device,  which  means  that  it  is  capable  of  routing  traffic. 
Unfortunately,  the  students  were  unable  to  program  a  routing  protocol  into  the  switch. 
Thus,  the  switch  could  not  automatically  establish  a  routing  table  to  talk  with  the  other 
wide  area  network  routers,  which  were  using  Enhanced  Interior  Gateway  Routing 
Protocol  (EIGRP).  Ross  Warren  from  Segovia  and  LT  Cordero  had  to  manually  input  all 
the  routes  into  the  routers  and  Cisco  3550  Switch  so  the  devices  would  know  where  to 
find  each  other. 

Finally,  single-channel  voice  communications  were  again  established  with  the 
PRC- 1 19s  and  PRC- 104s.  These  were  vital  assets  as  coordination  took  place  to  get  each 
of  the  links  established  and  to  conduct  the  days  test.  The  tethered  balloon  was  also 
employed  on  this  day  as  a  means  of  communication  between  the  NOC  and  the  POP  sites. 
The  tethered  balloon  and  the  satellite  link  were  not  redundant  communications,  but  they 
were  employed  separately  on  the  network.  In  order  to  do  this,  the  students  unplugged  the 
satellite  link  from  the  network  and  plugged  the  802.11b  link  into  the  same  ports  that  the 
satellite  was  hooked  into.  Figure  46  below  gives  further  detail  of  this  day’s  setup. 
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Figure  47.  9  MARCH  COMMUNICATIONS  ARCHITECTURE 

The  next  day  of  testing,  10  March,  was  the  first  attempt  to  incorporate  all 
scenarios  mentioned  above.  Communications  on-the-move  was  performed  by  MRC  #1 
and  #2,  as  both  vehicles  had  their  own  LAN  setup  in  the  vehicles.  The  objective  of  the 
experiments  with  these  vehicles  was  to  simulate  a  convoy  where  the  vehicles  did  not  have 
LOS  communications.  Thus,  the  two  vehicles  drove  BLOS  of  each  other  and  OFDM 
technology  was  utilized  to  keep  the  vehicles  in  contact  with  each  other.  Next,  FSO  was 
employed  in  MRC  #1  and  #2  when  the  vehicles  planned  to  stop  and  attain  LOS  with  one 
another.  The  OFDM  link  and  FSO  were  not  used  simultaneously,  but  were  rather  used 
separate  from  each  other. 

The  lead  vehicle,  MRC  #1,  was  also  equipped  with  an  omni-directional  antenna  to 
establish  communication  with  the  POP  through  the  tethered  balloon  with  802.11b.  The 
same  setup  was  employed  at  the  POP  and  NOC  as  the  previous  day  with  the  Cisco  3550 
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Switch  at  the  POP  and  the  broadband  satellite  equipment  connecting  the  two  sites.  The 
addition  on  this  day  was  integration  of  an  UAV  into  the  setup.  This  platform  was 
employed  off  of  the  network  at  various  times  throughout  the  day  in  order  to  test  the 
reliability  of  its  communications  relay.  The  UAV  and  tethered  balloon  were  used  as 
aerial  relay  platforms  of  802.1  lb. 


Finally,  VHF  voice  communications  were  used  throughout  the  day.  This  greatly 
assisted  all  the  nodes  to  communicate  while  the  vehicles  were  in  motion.  Figure  47 
below  portrays  the  architecture  on  this  day. 


Figure  48.  10  MARCH  COMMUNICATIONS  ARCHITECTURE 

On  11  March,  except  for  one  change  at  MRC  #1  and  the  addition  of  the 

INMARSAT,  the  communications  architecture  was  the  same  as  the  previous  day.  MRC 

#1  and  #2  were  still  conducting  communications  on-the-move,  along  with  static 

connectivity  using  FSO.  At  MRC  #1,  based  on  the  previous  day’s  lessons  learned,  the 

students  decided  to  place  the  Cisco  2950  switch  between  the  two  routers  in  order  to 
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facilitate  the  conneetions  of  802. 11b,  OFDM/FSO,  and  a  LAN.  During  the  previous  day, 
an  attempt  was  made  to  install  a  module  on  the  Ciseo  3745  router  that  had  multiple  IP 
ports.  Unfortunately,  the  ports  on  the  module  were  unable  to  perform  layer  3  eapabilities, 
so  the  students  had  to  employ  a  method  that  was  used  at  the  POP  on  the  first  day  of 
testing.  This  assisted  in  getting  the  LAN  established  at  MRC  #1. 

The  INMARSAT  link  was  utilized  at  MRC  #1,  but  eommunieations  were  never 
established  with  the  network.  Instead  of  using  it  as  originally  intended  in  place  of  the 
tethered  balloon,  the  students  used  the  INMARSAT  service  to  search  the  Internet  and 
make  test  phone  calls  while  on  the  move  in  MRC  #1.  A  phone  was  plaeed  at  MRC  #I 
and  at  the  NOC  to  test  the  phone  conneetivity. 


Once  again  single-ehannel  voiee  communications  were  utilized  between  all  the 
nodes  to  faeilitate  planning  and  eoordination.  Figure  48  below  displays  the  architeeture 
on  this  day. 


Figure  49.  1 1  MARCH  COMMUNICATIONS  ARCHITECTURE 
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The  ultimate  goal  of  this  testing  event  was  to  determine  whieh  of  the  technologies 
evaluated  proved  useful  while  employed  during  the  above  scenarios.  In  addition,  the 
authors  evaluated  how  the  technologies  reacted  to  one  another  when  merged  together 
throughout  the  WAN’s  communications  architecture.  The  focus  was  not  on  data 
collection  of  throughput  rates  as  in  previous  field  tests.  The  following  state-of-the-art 
wireless  technologies  were  tested:  Free  Space  Optics,  802.11b,  802.11a,  OFDM, 
INMARSAT,  and  Broadband  Satellite.  Voice  over  Internet  Protocol  (VoIP)  was 
implemented  in  the  local  area  networks  to  test  the  quality  of  service  over  this  multitude  of 
technologies. 

1.  Line-of-Sight  (LOS) 
a.  Lightpointe 

Lightpointe  supported  the  testing  evolution  from  March  7-9  with  Jim 
McGowan,  Sales  Director,  and  Albert  Borquez,  Network  Engineer.  They  brought  their 
FlightStrata  OC-3  FSO  Fly  Away  Package,  which  included  two  link  heads  for  end-to-end 
connectivity.  Lightpointe ’s  personnel  arrived  on  7  March  in  order  to  assist  in  the 
baseline  testing  being  conducted.  They  set  up  a  short  50-meter  link  on  this  day.  Due  to 
the  FlightStrata’ s  Auto  Power  Control,  the  short  distance  was  easily  accomplished.  They 
were  configured  similarly  to  the  Raytheon  testing  event  where  they  ran  a  multi-mode 
fiber  cable  from  the  link  head  to  a  media  converter  and  then  from  the  converter  to  the 
network  router  via  CAT-5  cable.  The  main  focus  of  this  day’s  experiments  was  to  ensure 
the  network  equipment  was  working  appropriately  before  gear  and  personnel  moved  to 
the  training  area  the  next  day. 

On  8  March,  Lightpointe  established  one  link  at  MRC  #1  and  the  other  at 
the  POP  site.  The  purpose  of  this  day’s  experiments  was  to  establish  connectivity  from 
the  NOC  to  the  POP  via  OFDM  and  from  the  POP  to  MRC  #1  through  FSO.  The 
distance  between  MRC  #1  to  the  POP  was  about  1,000  meters.  Terabeam  was  setup  at 
MRC  #1  as  well  on  this  day.  The  authors  managed  to  switch  the  links  of  both  companies 
in  and  out  of  the  network,  so  they  did  not  operate  simultaneously.  Figure  49  shows  the 
setup  of  the  links  at  MRC  #1 . 
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Figure  50.  LIGHTPOINTE  AND  TERABEAM  SETUP  AT  MRC  #1  ON  8  MARCH 


When  going  from  the  NOC  to  the  POP  via  OFDM  then  to  the  MRC  #1  site 
via  Lightpointe’s  FSO  link,  two  tests  were  eondueted  using  Iperf  on  8  Mareh.  A  sample 
set  of  data  from  this  experiment  ean  be  found  in  Figure  50  below. 


Client  connecting  to  192.168.70.5,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.20.3  port  1420  connected  with  192.168.70.5  port  5001 


[  ID]  Interval 
[928]  0.0- 5.2  sec 
[928]  5.2-I0.I  sec 
[928]  I0.I-I5.0  sec 
[928]  15.0-20.0  sec 


Transfer 

2.7  MBytes 

1.8  MBytes 

3.9  MBytes 
3.4  MBytes 


Bandwidth 
4.1  Mbits/sec 

2.9  Mbits/sec 

6.3  Mbits/sec 

5.4  Mbits/sec 


[928]  0.0-20.3  sec  1 1.7  MBytes  4.6  Mbits/sec 


Figure  5 1 .  IPERF  DATA  FROM  NOC  TO  MRC  #I  ON  8  MARCH 
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While  these  data  rates  are  very  low  for  an  FSO  link,  the  bandwidth  was 
actually  dictated  by  the  OFDM  link  that  was  being  used  from  the  NOC  to  the  POP,  which 
was  BLOS.  See  the  Findings  and  Analysis  section  for  further  explanation. 

On  9  March,  Lightpointe  set  up  their  link  at  MRC  site  #1  once  again  with 
Terabeam.  MRC  site  #2  was  set  up  with  an  OFDM  link  between  the  site  and  the  POP, 
and  the  POP  was  connected  to  the  NOC  via  Segovia/Omega  Systems  satellite  link.  That 
way,  the  NOC  was  communicating  through  the  satellite  to  the  POP  and  from  there  to 
MRC  #1  via  FSO.  Although  the  links  were  successfully  established,  the  authors  were 
unable  to  ping  between  the  NOC  and  MRC  #1  on  this  day  due  to  routing  issues  on  the 
Cisco  3550  switch  at  the  POP. 

Overall,  Lightpointe  was  able  to  display  the  diversity  of  their  Fly  Away 
package  while  maneuvering  around  the  training  area.  Their  personnel  and  product 
support  was  top  notch  during  this  testing  evolution. 

b.  Terabeam 

Terabeam  supported  this  evolution  with  Craig  Campadore,  Sales,  and 
Wayne  Bailey,  Engineer,  from  March  7-9.  They  brought  Terabeam’s  outdoor  Elliptica 
OC-3  FSO  product  with  them.  The  personnel  from  Terabeam  arrived  on  7  March  to 
assist  the  students  with  baseline  testing  prior  to  deploying  to  the  training  area.  The 
Elliptica  link  was  setup  at  roughly  200  meters  end-to-end,  and  a  media  converter  was 
input  between  the  link  head  and  the  network  router.  Multi-mode  fiber  cable  was  used 
from  the  link  head  to  the  media  converter.  Since  the  main  focus  of  the  baseline  testing 
was  to  get  network  equipment  operating  properly,  the  Terabeam  link  was  not  tested  for 
throughput  ratings,  but  the  link  did  perform  flawlessly  on  this  day. 

On  8  March,  Terabeam’s  personnel  departed  for  the  training  area  to  set  up 
one  link  at  the  POP  and  the  other  at  MRC  #1.  The  goal  on  this  day  was  to  establish 
connectivity  between  the  NOC,  POP,  and  MRC  #1.  The  NOC  to  POP  communications 
was  via  OFDM,  and  the  POP  to  MRC  #1  was  via  FSO.  The  data  that  was  collected  was 
very  similar  to  what  Lightpointe  experienced.  The  OFDM  link  dictated  the  throughput 
from  the  NOC  to  MRC  #1 .  Since  the  throughput  of  the  OFDM  was  anywhere  between  2- 
12  Mbps  while  established  in  the  network,  the  FSO  link  pushed  through  what  was 
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coming  in.  Thus,  the  overall  throughput  data  obtained  from  the  NOC  to  MRC  #1  is 
reported  in  Figure  5 1  below.  This  data  was  collected  in  Iperf. 


Client  connecting  to  192.168.70.5,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.20.3  port  1420  connected  with  192.168.70.5  port  5001 


[  ID]  Interval  Transfer 

[928]  0.0-  5.2  sec  2.7  MBytes 
[928]  5.2-10.1  sec  1.8  MBytes 
[928]  10.1-15.0  sec  3.9  MBytes 
[928]  15.0-20.0  sec  3.4  MBytes 


Bandwidth 
4. 1  Mbits/sec 
2.9  Mbits/sec 

6.3  Mbits/sec 

5.4  Mbits/sec 


[928]  0.0-20.3  sec  11.7  MBytes  4.6  Mbits/sec 


Figure  52.  IPERF  DATA  FROM  NOC  TO  MRC  #1  VIA  OFDM  AND  FSO 


Terabeam  was  set  up  at  MRC  #I  on  9  March  as  well.  MRC  site  #2  was 
established  on  this  date  with  an  OFDM  link  connecting  the  site  to  the  POP.  The  satellite 
link  provided  by  the  Segovia/Omega  Systems  team  was  interconnecting  the  NOC  and 
POP  site.  Thus,  on  this  day  three  different  technologies  were  established  in  the  Wide 
Area  Network.  Unfortunately,  due  to  routing  problems  on  the  Cisco  3550  switch  at  the 
POP  site,  no  data  could  be  transferred  to  the  MRC  site  #1 . 

Terabeam’ s  support  was  superb  throughout  their  three  days  of  testing  at 
Camp  Roberts.  They  were  able  to  deploy  their  gear  throughout  the  training  area  and 
establish  connectivity  in  an  expedient  manner. 

c.  fSONA 

fSONA  responded  to  a  short  notice  request  to  support  this  testing  event 
with  their  FSO  technology.  Pablo  Bandera,  Product  Manager,  came  out  from  British 
Columbia,  Canada  with  fSONA’s  SONAbeam  155-E  FSO  product  that  supports  El  to 
OC-3,  rate-adaptive.  The  SONAbeam  155-E  is  a  lightweight  unit  that  is  optimized  for 
short-distance  links  from  50  meters  up  to  2,500  meters.  It  includes  two  redundant  high- 
powered  lasers  transmitting  at  1550  nanometers.49  During  this  testing  event,  the  155-E 

49  http://www.fsona.com/product.php?sec=155e  (April  2004). 
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sat  on  top  of  a  lightweight  telescopic  stand.  It  used  a  single-mode  fiber  cable  from  the 
link  head  to  the  media  converter,  and  then  from  the  media  converter  to  the  network 
router  via  a  CAT-5  cable.  Figure  52  shows  the  SONAbeam  155-E. 


Figure  53.  fSONA’s  SONABEAM  155-E50 

fSONA  was  integrated  into  the  testing  on  March  10-11  during  the 
communications  on-the-move  portion.  The  authors  arranged  to  use  Redline  and 
Alvarion’s  OFDM  link  between  the  two  vehicles  in  the  convoy  while  in  motion.  To 
incorporate  fSONA’s  equipment,  each  vehicle,  MRC  #1  and  MRC  #2,  was  equipped  with 
a  SONAbeam  155-E.  After  a  certain  amount  of  testing  was  done  with  OFDM,  the 
vehicles  stopped  on  the  side  of  the  road  and  attained  LOS  for  the  FSO  link.  This 
established  a  link  between  the  two  vehicles  at  about  500  meters.  The  goal  on  both  days 
with  fSONA  was  to  use  Segovia/Omega  Systems’  satellite  link  between  the  NOC  and 
POP,  the  802.11b  signal  between  the  POP  and  MRC  #1  thru  the  tethered  balloon,  and 
finally  the  FSO  link  between  MRC  #1  and  MRC  #2. 

Mr.  Bandera  set  up  the  two  links  within  25  minutes,  but  then  ran  into 
trouble  when  connecting  to  the  media  converters.  When  connecting  the  single-mode 
fiber  cable  to  the  media  converters,  the  converters  did  not  show  a  link  light.  This 
happened  on  both  days,  so  the  goal  of  establishing  connectivity  with  FSO  between  MRC 
#1  and  #2  was  not  accomplished.  See  the  Findings  and  Analysis  section  for  further 
explanation. 


50  http://www.fsona.com/product.php?sec=155e  (May  2004). 
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d.  802.11a  (Vehicles) 

On  several  occasions  at  different  sites  and  times,  the  Wireless  Access 
Point  (WAP)  55 AG  was  used  to  provide  a  802.11a  Wireless  LAN  (WLAN).  The 
computers  in  the  WLAN  were  equipped  with  WPC55AG  notebook  adaptors  to 
communicate  with  the  access  point. 

The  WAP55AG  actually  contains  two  separate  wireless  connectivity 
radio  transceivers,  which  support  802.1  la/b/g  popular  wireless  networking  specifications. 
The  first  transceiver  uses  the  2.4  GHz  radio  band,  supporting  both  the  widely  used  and 
inexpensive  Wireless-B  (802.11b)  standard  at  11  Mbps,  and  the  new,  almost  five  times 
faster,  Wireless-G  (draft  802. 11  g)  at  54  Mbps.  The  second  radio  operates  in  the  5  GHz 
band,  and  supports  Wireless-A  (802.11a)  networking,  also  at  54  Mbps.  Since  the  two 
radios  operate  in  different  bands,  they  can  work  simultaneously,  blanketing  a  wireless 
zone  with  high-speed  bandwidth.51 

e.  Voice  Over  Internet  Protocol  (VoIP) 

A  mixture  of  Cisco  7940G,  7960G,  and  7920  IP  telephones  were  used  to 
provide  voice  service  throughout  the  network.  The  7940G  and  7960G  phones  use  a 
simple  CAT-5  cable  connection,  while  the  other  end  was  connected  to  the  LAN  Cisco 
switch.  The  Cisco  Wireless  IP  Phone  7920  is  an  easy-to-use  IEEE  802.1  Ib  wireless  IP 
phone  that  provided  comprehensive  voice  communications  in  conjunction  with  Cisco’s 
Call  Manager  product.  At  the  NOC,  the  wireless  7920  IP  telephone  was  utilized  with  a 
Linksys  802.1  lb  access  point  attached  to  the  LAN  switch.  The  Call  Manager  server  was 
always  located  at  the  NOC.  The  phones  throughout  the  two  LANs  first  talked  to  the 
server  before  making  a  call  to  another  phone  within  the  network.  The  server  was 
connected  to  the  NOC  Cisco  2950  switch  via  CAT-5  cable.  Each  phone  and  the  server 
was  assigned  its  own  unique  IP  address.  Finally,  each  phone  had  a  phone  number 
assigned  to  it  by  the  server.  This  enabled  a  quick  call  to  any  phone  on  the  network. 

The  Voice  over  IP  protocol  employed  was  Cisco’s  Call  Manager  Skinny 
Client  Control  Protocol  (SCCP).  SCCP  is  a  Cisco  proprietary  protocol  used  between 
Cisco  Call  Manager  and  Cisco  Voice  over  IP  phones.  This  protocol  is  also  supported  by 
other  vendors.  The  Cisco  IP  Phones  7960G  and  7940G  are  also  capable  of  supporting 


51  http://www.linksvs.cotn/products/product.asp?grid=33&scid=35&prid=538  (May  2004). 
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other  protocols  such  as  Session  Initiated  Protocol  (SIP),  and  Media  Gateway  Control 
Protocol  (MGCP).  However,  the  students  chose  to  use  the  SCCP. 

Finally,  the  link  between  the  NOC  and  POP  saw  no  quality  of  service 
issues  with  VoIP,  even  while  traversing  a  satellite  link  that  was  double  hopping  from  the 
NOC  to  the  POP.  There  was  a  slight  delay  when  talking  but  the  clarity  of  voices  was 
nearly  perfect.  Even  when  communicating  from  the  NOC  to  the  POP  via  satellite  link 
and  then  to  MRC  #1  and  #2  sites  via  FSO  or  OFDM,  the  quality  of  service  was  not 
affected.  Testing  was  not  conducted  evaluating  VoIP  when  the  vehicles  were  on  the 
move. 

2.  Beyond  Line-of-Sight  (BLOS) 
a.  Alvarion 

Alvarion  supported  this  testing  event  from  March  8-11  with  Soria 
Constantino,  Field  Technician,  from  Carlsbad,  CA.  Mr.  Constantino  brought  with  him 
Alvarion’ s  BreezeACCESS  VL  system.  This  system  offers  non-line-of-sight  (NLOS) 
point-to-multipoint  or  point-to-point  solutions  in  the  5  GHz  band  5.725-5.850  GHz  and 
5.47-5.725  GHz.  The  BreezeACCESS  uses  OFDM  technology  to  overcome  obstacles, 
such  as  trees,  buildings,  and  hills  for  quick  and  effortless  NLOS  deployments.  It  can 
operate  at  speeds  of  6  Mbps,  24  Mbps,  and  54  Mbps.  The  system  comes  with  indoor  and 
outdoor  units.  The  indoor  unit  is  a  lightweight,  handheld  device  that  is  powered  by 
110V/220V  AC.  It  has  an  RJ-45  port  to  run  CAT-5  cable  from  the  unit  to  a  network 
device,  such  as  a  router  for  this  testing  event.52  This  unit  is  shown  in  Figure  53  below. 


Figure  54.  BREEZEACCESS  VL  INDOOR  IJNIT53 


52  http://www.alvarion.com/RunTime/Products  2020.asp?tNodeParam=30  (April  2004). 

53  Alvarion,  “Broadband  Wireless  Access  Brief’,  February  2004. 
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The  outdoor  unit  consists  of  an  antenna  and  radio,  which  is  built  into  the 
antenna.  The  antenna  can  produce  sector,  omni-directional,  or  tight  beam  radiation 
patterns.  There  is  an  RJ-45  port  on  the  outdoor  unit  as  well,  which  connects  to  the  indoor 
unit  via  a  CAT-5  cable.  This  unit  is  depicted  in  Figure  54  below. 


Figure  55.  BREEZEACCESS  VL  OUTDOOR  UNIT54 

During  the  testing  event  on  8  March,  Alvarion  set  up  a  point-to-point  link 
at  Camp  Roberts  between  the  NOC  and  POP  sites.  This  setup  was  BEOS  over  a  hill  that 
was  roughly  100-200  feet  tall  with  trees  sporadically  located  between  the  links.  At  the 
NOC  site,  the  antenna  was  set  on  a  mast  that  was  raised  to  about  20  feet  high.  At  the 
POP  site,  the  antenna  was  also  on  a  similar  mast  of  20  feet.  Both  of  these  antennas  were 
two-foot  uni-directional  antennas  with  a  28.5  dBi  gain  and  3  dB  beamwidth  of  4.5 
degrees.  The  data  collected  going  from  the  NOC  to  the  POP  via  Alvarion’ s  link  showed 
that  12  Mbps  of  data  was  being  transferred  when  using  Iperf  (64  Kbyte  size  packets). 
When  going  from  the  NOC  to  the  POP  over  Alvarion’s  link  and  then  from  the  POP  to 
MRC  #1,  where  an  FSO  link  was  established,  the  data  from  Iperf  (64  Kbyte  size  packets) 
showed  5.4  Mbps  of  throughput.  Alvarion  also  had  a  program  called  Q-Check  that  ran 
throughput  tests  over  the  link.  Q-Check  is  a  network  troubleshooting  utility  that  checks 
network  response  time,  throughput,  and  streaming  performance. 5 5  This  throughput  data 
ranged  between  4—12  Mbps  when  going  from  a  computer  on  the  LAN  at  the  NOC  site  to 
a  computer  on  the  LAN  at  the  POP  site.  The  setup  time  during  this  day  was  about  one 

54  Alvarion,  “Broadband  Wireless  Access  Brief’,  February  2004. 

55  http://www.ixiacom.com/products/performance  annlications/pa  displav.php?skev=pa  q  check 
(May  2004). 


120 


hour  for  the  Alvarion  link  between  the  NOC  and  POP  sites,  but  Mr.  Constantino  was 
working  alone  so  he  had  to  go  baek  and  forth  between  the  two  sites. 


On  9  Mareh,  Alvarion  deployed  out  to  the  MRC  #2  and  POP  sites  with  the 
same  equipment  as  the  previous  day.  The  1,000-meter  link  was  set  up  BLOS,  and  the 
terrain  between  the  sites  was  hilly  with  numerous  trees  throughout  the  landscape.  Since 
the  focus  was  on  establishing  the  network  with  the  Cisco  3550  Switch  at  the  POP  site,  the 
researchers  did  not  collect  data  during  this  day.  Although  it  took  most  of  the  day  to 
establish  a  connection,  by  1700  connectivity  from  MRC  #2  over  the  OFDM  link  was 
solid  to  the  POP  and  NOC;  however,  connectivity  to  MRC  #1  was  not  established  due  to 
routing  configuration  issues  at  the  POP  switch. 

Overall,  Alvarion ’s  equipment  and  support  were  solid  throughout  the 
week.  The  biggest  consideration  when  using  the  Breeze  ACCESS  VL  is  the  type  of 
antenna  since  there  are  numerous  sector  antennas  as  well  as  omni-directional  ones.  A 
user  must  evaluate  the  scenario  to  determine  what  type  of  antenna  to  utilize. 

b.  Redline  Communications 

This  testing  event  was  the  first  time  the  students  were  able  to  work  with 
Redline  Communications.  Dave  Rumore,  Sales  Representative,  and  Don  Mullin, 
Engineer,  supported  this  event  from  March  8-10.  They  brought  with  them  their  AN-50 
OFDM  system  with  sector,  narrow  beam  point-to-point  and  omni-directional  antennas. 
The  AN-50  system  operates  in  the  license-exempt  5.8  GHz  band  and  includes  advanced 
technologies  to  address  potential  inter-cell  interference  issues.  The  AN-50  maximizes 
spectral  efficiency  with  a  unique  patented  bi-directional  adaptive  modulation  technique, 
automatically  selecting  any  of  eight  modulation  schemes  providing  a  solid  connection 
even  in  challenging  link  conditions.  Furthermore,  the  AN-50  delivers  an  over-the-air  rate 
of  up  to  72  Mbps,  a  robust  NLOS  capability,  and  audible  antenna  alignment  and 
diagnostic  capabilities. 56 

The  essence  of  OFDM  is  that  it  breaks  up  the  transmitted  signal  into 
many  smaller  signals,  as  shown  in  Figure  55  below. 


56  Redline  Communications,  “Redline  Family  White  Paper”,  October  2003. 
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Figure  56.  OFDM  CARRIER  BREAKDOWN57 


For  example,  instead  of  one  signal  carrying  72  Mbps  of  data,  there  are  48  separate 
carriers,  each  carrying  about  1 .5  Mbps  of  data  (in  the  case  of  the  Redline  product). 

One  key  aspect  of  OFDM  implementation  is  that  the  individual  carriers 
overlap  significantly  to  preserve  overall  bandwidth.  Normally,  overlapping  signals 
would  interfere  with  each  other,  however,  through  special  signal  processing,  the  carriers 
in  an  OFDM  waveform  are  spaced  in  such  a  manner  that  they  effectively  do  not  see  each 
other,  i.e.  they  are  orthogonal  to  each  other.58 

On  8  March,  Redline  set  up  one  of  their  sector  antennas  at  the  NOC  and 
the  other  sector  antenna  was  placed  at  the  POP  site.  A  distance  of  2,000  meters  with  a 
hill  and  sporadic  trees  in  between  separated  these  two  sites.  The  set  up  of  the  link  took 
much  longer  than  normal  due  to  the  lack  of  a  good  azimuth  between  the  two  sites.  When 
Redline  moved  from  the  NOC  to  the  POP,  they  had  a  rough  estimate  of  what  the  azimuth 
would  be  but  this  proved  insufficient.  After  an  hour,  Don  Mullin  returned  to  the  NOC 
from  the  POP  and  determined  that  the  antenna  at  the  NOC  site  was  way  off  from  where 
the  POP  site  was  set  up.  After  arranging  the  antenna  in  the  appropriate  direction, 
connectivity  came  up  right  away.  Once  the  links  were  configured  for  the  network, 
Redline  used  their  computers  and  connected  them  to  the  LAN  switches  at  both  sites. 
They  ran  their  Q-Check  program,  which  was  the  same  utility  used  by  Alvarion,  and  it 
produced  a  reading  between  5-11  Mbps  from  one  computer  to  the  other  while  varying  the 

size  of  the  packets.  Iperf  then  sent  64  Kbyte  size  packets  resulting  in  2.4  Mbps  from 

57  Redline  Communications,  “Second  Generation  High-Capacity  Broadband  Wireless  Solutions”, 
April  2003. 

58  Redline  Communications,  “Second  Generation  High-Capacity  Broadband  Wireless  Solutions”, 
April  2003. 
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computer  to  computer.  After  a  while,  Redline  took  their  computers  off  of  the  LAN  and 
hooked  them  directly  onto  the  links  resulting  in  a  reading  on  Q-Check  of  27  Mbps.  Most 
of  the  data  readings  varied  depending  on  the  size  of  the  packet  being  pushed  across  the 
link  and  where  the  computer  was  connected. 

One  observation  on  8  March  was  that  Redline’ s  AN-50  system  was  set  for 
auto-negotiation.  Nothing  was  done  on  this  day  to  change  the  setting  to  full  duplex,  and 
all  of  the  network  equipment  was  set  for  full  duplex.  This  could  have  been  another 
reason  why  the  readings  were  inconsistent.  Figure  56  below  shows  the  AN-50  system. 


Figure  57.  AN-50  SYSTEM 

On  9  March,  Redline  brought  their  equipment  out  to  MRC  #2  and  the 
POP.  They  used  the  same  equipment  as  the  day  before  with  their  sector  antennas 
mounted  on  five-foot  stands.  On  this  day,  the  terrain  was  less  conducive  to  establish 
connectivity  with  about  1,000  meters  between  the  sites,  due  to  more  hills  and  dense  tree 
lines.  This  was  a  good  test  to  see  if  their  equipment  could  perform  as  advertised.  Once 
the  equipment  was  aligned  and  set  up,  the  link  was  established  right  away.  Preparation 
was  made  ahead  of  time  to  get  a  good  azimuth.  An  advantage  of  Redline’s  AN-50 
system  is  that  it  has  an  audio  tone  that  indicates  link  alignment.  This  greatly  assists  those 
who  are  establishing  the  link.  Figure  57  below  shows  the  terrain  Redline  had  to  traverse 
on  this  day.  The  data  collected  on  9  March  from  Q-Check  was  showing  between  18-24 
Mbps  when  going  from  link  to  link  and  about  14  Mbps  when  running  it  on  the  LAN.  The 
throughput  drop  was  due  to  the  networking  equipment  (laptops,  switches,  and  routers). 
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Figure  58.  REDLINE’S  ANTENNA  ON  9  MARCH  AT  MRC  #2 


While  experimenting  on  this  day  with  the  auto-negotiation  on  the  AN-50 
system,  the  students  determined  that  the  system  would  go  to  full  duplex  if  a  switch  was 
placed  in  between  the  AN-50  system  and  the  LAN  router.  Thus,  the  hookup  went  from 
the  sector  antenna  to  the  AN-50  via  RF  cable,  then  from  the  AN-50  to  the  switch  via 
CAT-5,  and  from  the  switch  to  the  router  also  via  CAT-5.  The  link  also  proved  to  be 
more  stable  on  this  day. 

Overall,  Redline  Communications’  AN-50  products  performed  very  well. 
They  were  invited  by  two  Naval  Postgraduate  School  professors  to  conduct  further 
testing  with  NPS.  These  tests  are  at  Camp  Roberts,  CA  and  are  supported  by  Special 
Operations  Command. 

c.  Balloon  802.11 

The  tethered  balloon  is  approximately  12  feet  in  diameter  when  fdled  with 
helium.  Several  tanks  of  helium  are  needed  for  operation  of  the  balloon,  and  it  takes 
roughly  an  hour  to  completely  fdl  the  balloon.  While  airborne,  the  balloon  does  not 
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perform  well  in  high  winds.  If  winds  are  over  20  mph,  the  balloon  should  not  be  flown  to 
alleviate  possible  damage.  In  addition,  due  to  the  constant  movement  of  the  balloon  in 
high  winds,  steady  connectivity  can  be  challenging. 

The  balloon  can  carry  a  payload  of  up  to  50  pounds,  which  is  located 
underneath  the  balloon.  For  the  March  testing,  the  payload  was  about  20  pounds  and 
contained  an  omni-directional  antenna,  access  point,  1-Watt  Amplifier,  DC  to  AC  power 
converter,  and  two  Lithium  batteries  used  as  the  power  source.  A  research  associate  at 
NFS,  Kevin  Jones,  built  this  payload.  Figure  58  below  shows  the  actual  payload  with  the 
access  point  and  antenna  located  on  the  bottom  and  one  lithium  battery  located  on  each 
side. 


Figure  59.  TETHERED  BALLOON  PAYLOAD 

To  deploy  or  retrieve  the  balloon,  an  attached  motor  controls  a  large  reel 
of  rope.  The  balloon  could  reach  an  altitude  of  approximately  3,000  feet.  To  fly  the 
balloon,  a  large  open  area  is  needed  because  high  winds  can  cause  the  balloon  to  be 
pushed  in  a  horizontally  rather  than  vertically.  Figure  59  below  shows  the  balloon 
system  deployment/retrieval  mechanism. 
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Figure  60.  BASE  OF  THE  TETHERED  BALLOON 


On  8  March,  the  tethered  balloon  was  first  launched  to  conduct 
connectivity  tests  that  were  separate  from  the  established  network.  The  balloon  was 
deployed  to  about  800  feet  and  the  wind  was  relatively  calm. 

The  balloon’s  access  point  was  a  Linksys  WAPl  1.  This  device  was  set  to 
run  in  bridge  mode.  On  this  day,  another  WAP  11  on  the  ground  was  used  in  bridge 
mode.  The  WAPl  1  has  a  web  interface  to  configure  the  device.  Entering  the  IP  address 
of  the  access  point  into  the  URL  line  on  Internet  Explorer  can  access  the  web  interface. 
Before  doing  this,  the  computer  that  is  connected  to  the  access  point  via  CAT-5  cable 
must  be  on  the  same  subnet  as  the  IP  address  assigned  to  the  access  point.  For  example, 
if  the  IP  address  for  the  access  point  is  192.168.2.150,  then  the  IP  address  for  the 
computer  configuring  the  access  point  must  be  192.I68.2.X.  In  addition,  after  the  IP 
addresses  are  set,  the  Media  Access  Control  (MAC)  address  from  the  other  access  point 
must  be  entered  for  the  access  point  that  is  being  configured.  Furthermore,  the  gateway 
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must  be  set  to  the  IP  address  of  the  other  access  point.  This  had  to  be  done  for  each 
access  point  on  the  ground  as  well  as  in  the  air.  Figure  60  below  gives  an  example  of  the 
Linksys  web  interface  configuration  page. 


Figure  6 1 .  WAP  1 1  WEB  INTERFACE  CONFIGURATION  HOMEPAGE 


Overall,  the  initial  test  conducted  on  this  day  was  point-to-point  with  both 
access  points  configured  in  bridge  mode.  The  access  point  on  the  ground  utilized  the 
regular  antennas  that  come  with  the  device,  and  the  access  point  on  the  balloon  was 
outfitted  with  an  omni-directional  antenna  with  a  5  dB  gain.  A  continuous  ping 
confirmed  proper  connectivity  between  the  two  sites.  There  was  a  95%  or  better  success 
rate  over  a  15 -minute  period. 

On  9  March,  the  balloon  was  launched  in  order  to  provide  connectivity 
between  the  NOC  and  POP.  Due  to  the  testing  of  the  satellite  link  between  the  two  sites, 
time  was  limited  to  establish  connectivity  through  the  balloon.  Both  the  POP  and  NOC 
had  LOS  with  the  balloon,  but  the  NOC  and  POP  were  BEOS. 
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In  order  to  attempt  to  establish  eonneetivity  from  the  NOC  to  the  POP  via 
the  tethered  balloon,  special  settings  needed  to  be  placed  on  the  WAP  11s.  Again, 
WAPl  Is  were  used  at  the  NOC,  POP,  and  on  the  balloon.  Each  site  had  omni-directional 
antennas  with  a  5  dB  gain.  The  WAP  11  on  the  balloon  was  set  for  bridge  mode  but  in 
point-to-multipoint  mode.  No  MAC  address  or  gateway  IP  address  was  necessary  for  this 
configuration.  At  the  NOC,  the  configuration  was  set  for  bridge  mode  with  a  remote 
MAC  address  of  the  access  point  on  the  balloon,  and  the  gateway  was  set  for  the  IP 
address  of  the  balloon’s  access  point.  At  the  POP,  the  configuration  was  the  same  as  the 
NOC.  Finally,  the  same  channel  and  Service  Set  Identifier  (SSID)  were  set  for  ah  three 
WAPl  Is. 

The  students  were  unable  to  establish  connectivity  between  the  NOC  and 
the  POP  on  9  March.  The  students  believed  this  was  due  to  the  position  of  the  omni¬ 
directional  antenna  on-board  the  balloon.  See  the  communications  on-the-move  section 
below  for  information  on  the  tethered  balloon  relay. 

d.  Unmanned  Aerial  Vehicle  (UAV)  802.11b 

MLB  Company  of  Mountain  View,  CA  supported  this  testing  event  from 
March  9-11  with  their  “Volcano”  UAV  platform.  The  55-pound  Volcano  aircraft  is 
designed  to  carry  a  15  lb  payload  up  to  an  altitude  of  12,000  feet.  A  50  cc  2-stroke 
gasoline  engine  was  customized  for  this  aircraft,  and  it  has  an  endurance  of  2  hours  at  40 
miles  per  hour.  Furthermore,  the  Volcano’s  flight  control  is  done  via  autonomous 
waypoint  navigation  or  direct  radio  control  uplink.  The  Volcano  UAV  has  been  actively 
flying  since  December  2002.59  Figure  61  shows  the  Volcano  aircraft. 


59  http://www.spvplanes.com/volcano.html  (May  2004). 


128 


Figure  62.  STEPHEN  MORRIS  AND  MLB’S  VOLCANO  UAV 


This  platform  was  utilized  for  communications  relay  during  the  testing 
event  for  nodes  scattered  throughout  the  training  area.  Kevin  Jones  from  NFS  built  a 
wooden  platform  that  was  placed  underneath  the  UAV.  It  contained  the  following: 
omni-directional  antenna,  Linksys  access  point,  1-Watt  amplifier,  DC  to  AC  power 
converter,  and  one  lithium  battery.  The  omni-directional  antenna  pointed  down  through 
the  wooden  platform.  This  platform  weighed  about  seven  pounds  and  was  attached  to  the 
UAV  via  three  metal  clipped  straps  that  wrapped  around  the  UAV  and  the  platform. 
Figure  62  shows  the  platform  attached  to  the  UAV. 
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Figure  63 .  MLB  VOLCANO  UAV  WITH  PAYLOAD 


On  9  March,  Stephen  Morris,  President  of  MLB,  and  Hank  Jones  arrived 
with  the  Volcano  and  conducted  familiarization  flights  along  with  some  initial  on-board 
communications  tests.  After  these  flights  and  tests,  the  wooden  platform  was  mounted  on 
the  UAV.  The  aircraft  was  controlled  with  a  handheld  device  by  Mr.  Morris  to  maneuver 
on  the  runway  and  take  off.  Only  500  meters  of  runway  was  needed  to  get  the  aircraft  off 
the  ground.  After  the  UAV  entered  its  flight  pattern,  which  was  programmed  into  the 
computer  system  that  goes  along  with  the  aircraft,  the  students  started  to  conduct 
communications  testing  with  the  aerial  platform. 

The  computer  system  and  antenna  used  to  control  the  Volcano  can  be  seen 
in  Figure  63.  The  frequency  to  control  the  aircraft  was  900  MHz  and  the  on-board 
camera  used  the  2.4  GHz  band  to  transmit  live  video  back  to  the  ground  control  station. 
In  the  computer  software  program  that  was  utilized  to  control  the  aircraft  while  in  flight, 
waypoints  and  altitude  information  were  entered  onto  a  digital  map  of  the  desired  flight 
pattern  of  the  aircraft.  Thus,  as  long  as  the  ground  antenna  had  LOS  with  the  aircraft  no 
manual  movement  with  the  handheld  device  was  required  while  the  aircraft  was  in  flight. 
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Consequently,  the  software  allowed  the  user  to  view  the  exact  pattern  of  the  entire  flight 
on  a  digital  map  after  mission  completion. 


Figure  64.  MLB  FLIGHT  CONTROL  GEAR  FOR  VOLCANO 


During  the  flight  on  9  March,  802.11b  connectivity  was  attempted  from 
the  NOC  to  the  POP  via  the  UAV.  Linksys  WAPl  1  Access  Points  were  used  at  each  site 
and  omni-directional  antennas  with  5  dB  gain  and  1-Watt  amplifiers  were  employed  with 
the  access  points.  The  setup  of  the  access  points  was  the  exact  same  as  the  configuration 
explained  in  the  tethered  balloon  section.  The  ground  access  points  were  set  for  point-to- 
point  in  bridge  mode  with  the  MAC  address  of  the  access  point  on  the  UAV  and  a 
gateway  IP  address  of  the  UAV’s  access  point.  The  airborne  access  point  was  set  on 
point-to-multipoint  with  no  gateway  IP  address.  Unfortunately,  very  few  pings  were 
attained  during  ping  connectivity  testing  on  this  day  with  the  existing  antennas,  despite 
the  UAV’s  altitude  of  500  feet  and  flying  directly  between  both  the  NOC  and  POP. 
Upon  further  research,  the  students  determined  that  the  omni-directional  antenna  on  the 
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UAV  was  not  positioned  very  well.  More  success  would  have  been  attained  with  the 
antenna  by  placing  it  on  the  aircraft  in  a  position  that  allows  for  the  most  optimal 
radiation  pattern. 

e.  NetMeeting 

NetMeeting  is  a  Microsoft  Windows  product  that  delivers  an  open, 
extensible  platform  for  real-time  communications,  offering  audio,  video,  and  data 
conferencing  functionality. 

During  this  testing  event,  the  students  utilized  NetMeeting  as  a  tool  to 
transmit  live  video  between  the  sites  via  Logitech  cameras  set  up  in  each  LAN,  to  talk  via 
headsets  hooked  up  to  the  computer,  and  to  perform  data  messaging  between  users  at  all 
sites.  On  1 1  March,  MRC  #2  was  able  to  see  video  in  NetMeeting  after  traversing  a 
satellite  link,  802.1  lb  through  the  tethered  balloon,  and  OFDM  from  the  NOC. 

f.  VoIP 

See  the  LOS  section  for  VoIP  explanation  during  the  testing  event.  No 
direct  testing  was  done  with  VoIP  when  traversing  solely  BLOS  technology  (OFDM, 
tethered  balloon,  or  UAV).  Instead,  IP  phones  were  employed  through  a  multitude  of 
technologies.  For  example  on  9  March,  when  MRC  #2  wanted  to  talk  to  the  NOC  over 
the  IP  phone,  the  phone  would  first  communicate  with  the  Call  Manager  server  over 
OFDM  and  then  through  the  broadband  satellite  link  resulting  in  a  successful  phone 
connection.  There  was  a  slight  delay  when  talking  through  these  means  but  the  quality  of 
service  was  not  affected.  However,  when  making  a  phone  call  on  1 1  March  from  MRC 
#1  through  the  tethered  balloon  to  the  POP  and  then  to  the  NOC  via  satellite,  there  were 
quality  of  service  issues  as  the  link  between  MRC  #1  and  the  POP  over  the  balloon  was 
experiencing  more  than  20%  packet  loss.  The  phone  would  occasionally  lose 
connectivity  due  to  this  packet  loss. 

3.  Over-the-Horizon  (OTH) 

a.  Segovia/Omega  Systems 

Segovia  and  Omega  Systems  supported  this  exercise  from  March  7-11 
with  Jeff  Howard,  Sales  Director,  and  Ross  Warren,  Senior  Sales  Engineer,  from  Segovia 
and  Matt  Jones,  Vice  President  Business  Development,  from  Omega  Systems.  Segovia  is 
the  service  provider  of  the  satellite  system  and  Omega  Systems  produces  the  satellite 
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dishes.  During  this  event,  a  one-meter  satellite  ground  terminal  was  utilized  at  the  NOC, 
and  a  mounted  one-meter  satellite  terminal  on  a  Sports  Utility  Vehiele  was  employed  at 
the  POP.  The  ground  terminal  is  a  multiple  ease  system  that  is  powered  by  a  llOV 
source,  and  its  transmitting  frequency  is  between  13.75-14.50  GHz  with  a  receiving 
frequency  between  11.70-12.75  GHz.  This  satellite  dish  is  manually  pointed  at  the 
satellite  for  connectivity.  Figure  64  below  shows  the  ground  terminal  in  the  foreground. 


Figure  65.  SEGOVIA/OMEGA  SYSTEMS  GROUND  TERMINAL 


The  mounted  terminal  requires  the  same  power  load  and  it  operates  in  the 
same  frequency  band.  However,  it  automatically  aligns  itself  to  the  satellite  once  it  is 
turned  on.  This  yields  for  a  quick  setup  time  and  operations  of  the  equipment  can  begin 
within  minutes.  Figure  65  illustrates  the  mounted  satellite  terminal. 
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Figure  66.  OMEGA  SYSTEMS  MOUNTED  SATELLITE  TERMINAL 


Both  terminals  are  capable  of  Type  1  encryption  to  provide  for  a  secure 
satellite  connection,  and  the  throughput  for  the  services  can  range  from  128  Kbps  to  9 
Mbps. 

During  this  testing  event,  the  personnel  from  Segovia  and  Omega  Systems 
demonstrated  their  flexibility  with  the  setup  of  the  terminals  and  the  services  that  they 
provided.  Segovia’s  Ross  Warren  was  able  to  coordinate  with  his  headquarters  in  order 
to  arrange  for  the  airborne  satellite  to  act  as  a  retransmission  site  for  the  link  between  the 
NOC  and  the  POP  (The  satellite  link  was  double-hopping  between  the  NOC  and  POP). 
See  Figure  66  below  for  latency  between  the  NOC  and  POP.  From  the  table,  one  can  see 
the  time  is  roughly  one  second  to  ping  between  the  two  sites.  By  comparison,  within  a 
LAN  two  computers  can  ping  each  other  with  a  time  of  less  than  10  milliseconds. 
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Reply  from  192.168.5.20:  bytes=32  time=1032ms  TTL=123 
Reply  from  192.168.5.20:  bytes=32  time=101 1ms  TTL=123 
Reply  from  192.168.5.20:  bytes=32  time=1012ms  TTL=123 
Reply  from  192.168.5.20:  bytes=32  time=1021ms  TTL=123 

Ping  statistics  for  192.168.5.20: 

Packets:  Sent  =  4,  Received  =  4,  Lost  =  0  (0%  loss), 

Approximate  round  trip  times  in  milli-seconds: 

Minimum  =  101 1ms,  Maximum  =  1032ms,  Average  =  1019ms 

Figure  67.  LATENCY  DATA  WITH  SEGOVIA  LINK 

The  satellite  services  of  Segovia  were  only  intended  to  be  used  for 
retransmission,  not  for  Internet  connectivity  or  to  provide  phone  services.  Even  though 
Segovia  would  have  been  able  to  arrange  Internet  services  with  a  retransmission 
capability,  the  students  did  not  pursue  this  option.  Not  only  did  Mr.  Warren  provide 
customer  support  for  his  equipment,  but  he  also  went  above  and  beyond  by  assisting  the 
students  with  the  configuration  of  the  entire  network  of  routers,  switches,  access  points, 
and  IP  phones. 

On  7  March,  Segovia  established  their  satellite  links  and  became  familiar 
with  the  entire  network  setup.  They  had  to  configure  their  gear  appropriately  to  plug- 
and-play  with  CAT-5  cable  from  their  system  into  the  established  network  router. 

The  next  day  (8  March),  Segovia  spent  the  morning  arranging  with  their 
headquarters  to  retransmit  the  signal  between  the  NOC  and  POP.  In  the  late  afternoon, 
after  OFDM  testing  was  complete  between  the  NOC  and  POP,  Segovia  successfully 
tested  their  setup  while  connected  to  the  network. 

On  9  March,  Segovia  established  their  link  for  the  entire  day  with  the 
ground  terminal  at  the  NOC  and  the  mounted  dish  at  the  POP.  They  had  their  settings  for 
bandwidth  set  very  low,  which  was  not  even  close  to  their  maximum  capabilities  of  9 
Mbps.  Figure  67  below  shows  the  Iperf  test  conducted  on  the  link  between  the  NOC  and 
POP  with  64  Kbyte  size  packets  flooding  the  link. 
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Client  connecting  to  192.168.5.5,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.20.3  port  1433  connected  with  192.168.5.5  port  5001 


[  ID]  Interval 
[928]  0.0- 5.1  sec 
[928]  5.1-10.6  sec 
[928]  10.6-16.0  sec 
[928]  16.0-20.1  sec 
[928]  0.0-23.3  sec 


Transfer 
192  KBytes 
40.0  KBytes 
40.0  KBytes 
32.0  KBytes 
304  KBytes 


Bandwidth 
298  Kbits/sec 

59.1  Kbits/sec 
59.4  Kbits/sec 

62.2  Kbits/sec 
104  Kbits/sec 


Figure  68.  IPERF  DATA  ON  9  MARCH  FROM  SEGOVIA’S  LINK 


After  Segovia  arranged  for  their  bandwidth  eapabilities  to  be  mueh  higher 
on  10  Mareh,  Iperf  data  was  mueh  more  eonsistent  and  higher.  The  first  test  eondueted 
was  with  Iperf  when  no  IP  phone  traffie  or  data  was  being  sent  from  the  NOC  to  the  POP. 
Figure  68  shows  this  data. 


Client  connecting  to  192.168.5.20,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.20.3  port  1049  connected  with  192.168.5.20  port 
5001 


[  ID]  Interval 
[928]  0.0-  5.1  sec 
[928]  5.1-10.1  sec 
[928]  10.1-15.1  sec 
[928]  15.1-20.1  sec 
[928]  0.0-22.3  sec 


Transfer 
640  KBytes 
616  KBytes 
632  KBytes 
608  KBytes 
2.4  MBytes 


Bandwidth 
1.0  Mbits/sec 

986  Kbits/sec 
996  Kbits/sec 

987  Kbits/sec 
897  Kbits/sec 


Figure  69.  IPERF  DATA  ON  10  MARCH  WITH  SEGOVIA’S  LINK 


After  this  was  eomplete,  data  was  eolleeted  with  Iperf  on  the  satellite  link 
when  a  Ciseo  IP  Phone  was  utilized  to  plaee  a  eall  between  the  NOC  and  POP  (This  was 
a  phone  eall  plaeed  by  using  VoIP  within  the  network  not  Segovia’s  phone  serviees). 
When  the  Iperf  paekets  flooded  the  network,  the  IP  phone  started  experieneing  a  one  to 
two  seeond  delay,  but  voiee  quality  was  still  exeellent.  However,  it  beeame  evident  that 
the  bandwidth  would  drop  eonsiderably  when  a  phone  eall  took  plaee.  Figure  69  below 
illustrates  the  data  eolleeted. 
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Qieit  ocxinectii^  to  192. 168.5.20,  TCP  port  5001 
TCP  wndowsize:  63.0  KByte  (default) 


[928]  local  192.168.20.3  port  1052  connectedwth  192. 168.5.20 port  5001 

[  ID]  Interval  Transfo*  BancMdth 

[928]  0.0-5.2sec  MKBytes  282Klits/sec 

[928]  5.2-10.7  sec  40.0  KBytes  58.1Khit^sec 

[928]  10.7-15.1  sec  32.0  KBytes  58.9Khits/sec 

[928]  15.1-20.6sec  40.0 KBytes  58.1Khit^sec 

[928]  20.6-25.8 sec  40.0 KBytes  61.6Klit^sec 

[928]  25.^31.1  sec  40.0  KBytes  60.0Khit^sec 

[928]  31.1-35.3  sec  32.0  KBytes  61.3  Khits/sec 

[928]  35.3^.6sec  40.0 KBytes  60.3Khit^sec 

[928]  40.645.5  sec  48.0 KBytes  78.6Klit^sec 

[928]  45.5-50.3  sec  152  KBytes  252Khit^sec 

[928]  50.3-55.3  sec  40.0  KBytes  63.8  Khits/sec 

[928]  55.3-60.9  sec  40.0  KBytes  57.4Khit^sec 

[928]  60.^5.0sec  32.0 KBytes  62.3Klit^sec 

[928]  65.0-70.2 sec  40.0 KBytes  61.6Khit^sec 

[928]  70.2-75.8sec  40.0 KBytes  57.2Klit^sec 

[928]  75.8-80.1  sec  32.0  KBytes  59.2Khit^sec 

[928]  80.1-85.1  sec  40.0  KBytes  61.2Klit^sec 

[928]  85.1-90.8 sec  192KBytes  270Khit^sec 

[928]  90.^95.2 sec  32.0 KBytes  58.8Klits/sec 

[928]  95.2-100.3  sec  40.0  KBytes  623  Khits/sec 

[  ID]  Lta^  Transfo*  BancMdth 

[928]  0.0-103.2  sec  1.1  91.1Khit^sec 


Figure  70.  SEGOVIA  IPERF  DATA  ON  1 0  MARCH  WITH  IP  PHONE 


The  last  day  of  the  testing  was  a  complete  success  as  Segovia’s  link 
provided  a  stable  connection  between  the  NOC  and  POP  as  the  students  worked  to 
establish  802.1  lb  through  a  tethered  balloon  and  OFDM  on-the-move  throughout  the  rest 
of  the  network. 


Overall,  Segovia  and  Omega  Systems  provided  a  solid  satellite  link  with 
less  than  10  minutes  of  down  time  throughout  the  week.  They  proved  their  versatility  by 
being  able  to  use  the  satellite  as  a  retransmission  device  within  a  private  network. 
Normally,  they  are  an  Internet  and  phone  services  provider.  Furthermore,  the  mounted 
terminal  proved  to  be  a  package  that  Marines  could  utilize  with  a  mobile  unit.  With  its 
self-acquiring  capabilities,  the  unit  can  be  up  and  running  within  minutes.  Omega  is  also 
working  on  a  package  that  can  communicate  while  on  the  move. 
b.  Neva 

Nera  supported  this  exercise  from  March  9-11  with  Torgrim  Jorgensen, 

Senior  Sales  from  the  Norway  office,  and  Peter  Coffman,  Sales  Director  out  of  the  Texas 

office.  Nera’s  NWC  Voyager  system,  INMARSAT  capabilities  on-the-move,  was 

utilized  in  the  convoy  on  11  March.  In  addition,  Nera’s  World  Communicator  was 
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demonstrated  on  10  March  but  not  used  as  planned  during  this  testing  evolution.  See  the 
Appendix  for  further  explanation  of  the  NWC  Voyage  and  World  Communicator. 


During  this  testing,  the  NWC  Voyager  was  mounted  on  a  custom  built 
wood  platform  in  the  back  of  a  pickup  truck.  The  platform  was  specifically  built  so  that 
the  satellite  antenna  would  clear  the  bed  of  the  truck.  Figure  70  below  shows  this  set  up. 


Figure  7 1 .  NERA  INMARSAT  MOUNTED  ON  VEHICLE  PLATFORM 


The  objective  for  the  Nera  satellite  system  during  this  event  was  to  bounce 
the  signal  between  the  Voyager  at  MRC  #1  and  the  World  Communicator  at  the  NOC, 
much  like  what  Segovia/Omega  Systems  did  with  their  satellite  link.  This  would  be  the 
WAN  connection  between  the  two  LANs.  The  NWC  Voyager  on  MRC  #1  would 
provide  connectivity  for  the  entire  convoy  to  talk  back  to  the  NOC  since  there  was  an 
OFDM  link  between  the  vehicles.  Then,  the  NOC  would  communicate  with  the  POP  via 
Segovia’s  satellite  link  to  complete  the  connectivity  between  all  nodes.  However,  after 
two  days  of  working  on  the  above  configuration  it  was  determined  that  this  setup  could 
not  be  accomplished  with  the  available  gear  that  Nera  had  on  hand. 

In  order  to  test  the  capabilities  of  Nera’ s  system,  the  students  employed 
the  Internet  and  phone  connectivity  capabilities  in  MRC  #1  with  the  Voyager  system.  A 
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phone  was  connected  to  the  modem  in  MRC  #1  and  another  cellular  phone  was  placed  at 
the  NOC.  MRC  #1  was  also  equipped  with  a  laptop  that  connected  to  the  Voyager 
modem,  which  provided  Internet  connectivity.  Figure  71  below  shows  the  phone  and 
modem.  While  MRC  #1  was  in  motion  with  the  mounted  Voyager,  phone  calls  and  most 
file  downloads  were  performed  without  error.  When  the  look  angle  of  the  Voyager  was 
blocked  by  hills  next  to  the  vehicle,  the  download  capabilities  were  temporarily 
terminated. 


Figure  72.  NERA’S  PHONE  AND  MODEM 

During  the  first  phone  call  between  MRC  #1  and  the  NOC,  a  4.6  Kbps  rate 
was  used.  However,  during  the  second  phone  call,  a  64  Kbps  rate  was  used  and  the  voice 
quality  was  much  better.  Neither  of  the  rates  produced  any  noticeable  time  delay  during 
the  phone  call.  File  downloads  were  conducted  for  demonstration  of  the  Internet 
connectivity.  First,  a  1.2  Mbyte  file  took  11  minutes  and  35  seconds  to  download.  Next, 
a  2.8  Mbyte  file  took  16  minutes  and  32  seconds  to  download.  Since  the  link  between 
MRC  #1  and  the  NOC  with  Nera’s  equipment  could  not  be  accomplished,  the  World 
Communicator  was  not  used. 

Overall,  Nera  was  able  to  demonstrate  their  capabilities  on  the  move.  The 
Nera  representative  did  explain  that  they  could  make  the  configuration  work  that  was 
originally  intended  if  they  had  the  appropriate  equipment.  This  LAN-to-LAN 
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connectivity  would  have  shown  the  ability  to  maintain  connectivity  while  on  the  move. 
A  scenario  that  this  is  applicable  to  is  when  main  and  forward  command  posts  echelon, 
which  usually  causes  them  to  lose  most  of  their  data  capabilities,  but  with  INMARSAT 
these  command  posts  could  continue  to  exchange  desired  data. 

c.  VoIP 

Within  the  LOS  section,  VoIP  is  explained  in  greater  detail.  One  of  the 
main  objectives  for  the  VoIP  element  was  to  determine  if  there  was  any  quality  of  service 
issues  over  a  satellite  link.  The  link  between  the  NOC  and  POP  was  a  Segovia/Omega 
System  satellite  service,  and  there  was  no  quality  of  service  issues  with  VoIP,  despite  this 
link  traversing  two  hops  from  the  NOC  to  the  POP.  There  was  a  slight  delay  when 
talking  but  the  clarity  of  voices  was  near  perfect.  Finally,  several  IP  phone  calls  could 
have  overloaded  the  satellite  link’s  throughput  of  1  Mbps  and  caused  a  quality  of  service 
issue. 

4.  Communications  on-the-Move 
a.  OFDM 

(1)  Redline  Communications.  On  10  March,  Redline’s  equipment 
was  deployed  on-the-move.  The  sector  antennas  were  placed  on  five-foot  stands 
mounted  on  a  wooden  platform  in  the  vehicles.  The  sector  antennas  had  60-degree 
beamwidth  and  the  other  was  a  tighter  beam  of  5-degrees.  The  AN-50  system  was  placed 
within  the  bed  of  the  pick-up  trucks.  The  goal  of  the  on-the-move  portion  was  to 
maintain  connectivity  via  OFDM  while  the  two  convoy  vehicles  were  BLOS.  As  the 
vehicles  started  in  motion,  both  MRC  #1  and  #2  established  a  continuous  ping  test.  This 
enabled  the  students  to  see  how  well  the  link  maintained  connectivity.  The  results  were 
favorable  since  connectivity  was  seldom  lost  and  only  for  seconds  when  vehicles  turned 
comers  or  when  a  hill  interfered.  This  was  also  being  done  with  sector  antennas,  so  this 
could  have  played  a  role  in  the  degraded  connectivity.  At  the  end  of  the  day,  Redline 
established  an  omni-directional  antenna  with  a  sector  antenna  to  ensure  that  connectivity 
was  maintained.  This  also  worked  and  may  be  a  better  solution  if  the  omni-directional 
antenna  has  enough  gain  to  meet  the  distance  of  the  convoy.  Figure  72  below  shows 
Redline’s  setup  for  the  communications  on-the-move. 
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Figure  73.  REDLINE  ON-THE-MOVE  SETUP  ON  BOTH  VEHICLES 


(2)  Alvarion.  Because  of  a  lack  of  time,  Alvarion  did  not  deploy 
their  system  on-board  MRC  #1  and  #2  on  10  March  while  communications  on-the-move 
were  being  evaluated.  However,  Mr.  Constantino  attempted  to  use  Alvarion’s  802.11b 
omni-directional  system  to  establish  connectivity  with  the  UAV  while  it  was  airborne. 
Unfortunately,  the  UAV  had  a  Linksys  AP  on-board  which  was  not  compatible  with  any 
other  type  of  equipment. 

On  11  March,  Alvarion’s  equipment  was  employed  on  MRC  #1 
and  #2  to  establish  connectivity  between  the  vehicles  while  on-the-move.  One  vehicle 
employed  an  AU-VL  5.8  GHz  Omni  antenna  with  an  8  dB  gain.  The  other  vehicle 
utilized  a  SU-VL  integrated  antenna  with  a  10-degree  beam  width.  The  integrated 
antenna  had  a  21  dB  gain.  While  on  the  move  and  with  the  vehicles  BEOS  of  each  other, 
the  OFDM  link  was  stable  as  both  vehicles  were  continuously  pinging  each  other.  There 
were  a  couple  of  areas  where  connectivity  was  lost  between  the  vehicles.  This  mostly 
occurred  as  one  vehicle  would  turn  a  comer  and  get  a  hill  between  the  two  vehicles.  The 
lapse  of  coverage  only  happened  momentarily  as  the  link  reestablished  itself  No  data 
was  collected  using  Iperf  or  Q-Check.  Figure  73  below  shows  the  antenna  setup  on  the 
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convoy  vehicles.  The  antennas  were  mounted  on  a  pole  that  was  attached  to  a  tripod.  The 
tripod  was  then  bolted  down  to  a  wooden  platform  in  the  bed  of  the  truck. 


Figure  74.  ALVARION  ANTENNA  SETUP  ON  POLE 

b.  802.11b  (balloon) 

On  10  March  the  lead  vehicle  in  the  convoy,  MRC  #1,  was  equipped  with 
an  omni-directional  antenna.  Connectivity  was  attempted  between  MRC  #1  and  the  POP 
site  via  the  tethered  balloon.  The  setup  of  the  WAPl  Is  at  MRC  #1,  POP,  and  the  balloon 
were  the  exact  same  as  explained  above  in  the  BEOS  section.  When  attempting  the  relay 
from  the  NOC  to  the  POP  on  9  March,  again  connectivity  could  not  be  established 
between  the  two  nodes.  Ping  tests  were  being  done  that  showed  the  lack  of  connectivity. 

Next,  MRC  #1  reconfigured  the  WAP-1 1  in  order  to  establish  connectivity 
with  the  tethered  balloon  directly  while  stopped  on  the  side  of  the  road.  Again,  the 
configuration  was  similar  to  what  was  set  up  on  8  March  between  the  NOC  and  the 
tethered  balloon.  This  time  MRC  #1  used  a  Yagi  directional  antenna  with  a  beamwidth 
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of  30  degrees  and  gain  of  14.5  dB.  And  for  the  first  time,  suceessful  pings  were 
established  between  the  two  nodes.  After  this  was  aeeomplished,  both  MRC  #1  and  the 
POP  utilized  the  same  Yagi  antennas  and  intermittent  conneetivity  was  attained  between 
the  two  sites  via  the  balloon.  This  day  was  fairly  windy,  so  the  balloon  was  moving  quite 
a  bit  while  deployed  to  1,000  feet.  When  condueting  ping  tests  between  the  POP  and 
MRC  #1,  a  50%  packet  loss  was  recorded. 

A  calm  day  on  1 1  March  proved  to  be  more  suitable  for  the  deployment  of 
the  balloon  as  results  showed  much  more  stable  connectivity.  The  same  setup  was 
employed  as  on  10  March  with  MRC  #1  and  the  POP  using  Yagi  antennas  connected  to 
the  WAPl  Is  and  MRC  #1  stationary.  The  reason  for  testing  while  stationary  was  that  the 
Yagi  antenna  needed  to  be  placed  on  a  mount  to  maintain  connectivity  with  the  balloon. 
If  the  vehicle  was  moving,  the  antenna  would  have  been  required  to  be  manually  pointed 
at  the  balloon.  A  tracking  antenna  on  the  ground  would  be  much  more  suitable  for  this 
type  of  operation. 

c.  802.11b  (UAV) 

On  10  March,  MRC  #1  was  equipped  with  a  Linksys  WAP  11  and  an 
omni-directional  antenna  with  a  1-Watt  amplifier.  Connectivity  was  attempted  from 
MRC  #1  on  the  move  with  the  NOC  through  the  Volcano  UAV.  The  UAV  was  flying  at 
500  feet  between  the  two  sites  and  within  LOS.  The  students  were  unable  to  establish 
connectivity  while  pinging  from  the  NOC  to  MRC  #1.  Next,  the  convoy  of  vehicles 
stopped  and  MRC  #1  set  up  a  Yagi  antenna  with  14.5  dBi  gain  and  configured  the  access 
point  to  go  point-to-point  with  the  airborne  access  point.  The  UAV  landed  and  the  access 
point  was  also  reconfigured  for  point-to-point  with  MRC  #1.  After  reestablishing  its 
track  at  500  feet,  MRC  #1  tracked  the  UAV  manually  with  the  Yagi  antenna  and  started 
to  see  better  connectivity.  Eighteen  of  22  pings  were  successful.  The  UAV  went  up  to 
1,000  feet  and  the  ping  ratio  decreased  to  two  of  20  successful  pings.  At  800  feet,  the 
ratio  was  six  of  20  pings.  With  the  lack  of  communications  relay  on  this  day,  the  UAV 
platform  was  never  integrated  into  the  wide  area  network. 

Testing  the  next  day  resulted  in  little  change  as  far  as  retransmission. 

Connectivity  was  attempted  from  the  NOC  to  the  POP  once  again  but  this  time  the  POP 

had  a  Yagi  antenna  tracking  the  UAV.  No  successful  pings  were  attained  even  while  as 

143 


low  as  400  feet.  Figure  74  below  illustrates  the  view  of  the  UAV  looking  down  on  the 
POP  site.  As  mentioned  earlier,  the  omni-directional  antennas  needed  to  be  better  placed 
on  the  aircraft  to  allow  the  radiation  pattern  of  the  antenna  to  emit  its  proper  signature. 
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Figure  75.  UAV  LOOKING  DOWN  ON  POP  SITE  ON  1 1  MARCH 

Overall,  MLB  Company  remained  flexible  throughout  the  three  days  of 
testing.  They  flew  at  varying  altitudes  and  changed  course  numerous  times  to  meet  the 
needs  of  the  experiment.  They  were  able  to  provide  the  support  the  students  expected, 
but  prior  testing  needed  to  be  done  to  test  the  antenna  set  up. 

d.  802.11a  (vehicles) 

The  Wireless  802.11a  LAN  in  the  moving  vehicles  on  March  10-11  was 
especially  helpful  as  the  networking  equipment  (routers,  switches,  access  point)  were  all 
located  in  the  bed  of  the  pick-up  trucks.  The  operator  with  the  laptop  was  located  in  the 
passenger  side  of  the  vehicle.  Therefore,  the  operator  did  not  have  to  run  a  cable  between 
the  bed  of  the  truck  and  the  cab.  Tests  were  not  conducted  to  determine  the  actual 
throughput  of  the  802. 1  la  link. 

This  field-testing  event  proved  very  challenging  due  to  the  complexity  of 
the  network  and  the  numerous  moving  parts.  However,  after  battling  through  the  issues 
that  came  up,  the  network  communications  architecture  that  was  desired  for  CoNDOR 
was  accomplished  on  the  last  day.  Figure  75  shows  the  connectivity  between  the  NOC 
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and  MRC  #2.  The  ping  test  went  through  three  different  technologies:  satellite  link, 
802.1  lb  retransmitted  through  a  tethered  balloon,  and  OFDM. 


From  .20.3  to  .80.3: 

Pinging  192.168.80.3  with  32  bytes  of  data: 

Reply  from  192.168.80.3:  bytes=32  time=1031ms  TTL=120 
Reply  from  192.168.80.3:  bytes=32  time=1052ms  TTL=120 
Reply  from  192.168.80.3:  bytes=32  time=1051ms  TTL=120 
Request  timed  out. 

Reply  from  192.168.80.3:  bytes=32  time=1041ms  TTL=120 
Reply  from  192.168.80.3:  bytes=32  time=1072ms  TTL=120 
Reply  from  192.168.80.3:  bytes=32  time=1032ms  TTL=120 
Reply  from  192.168.80.3:  bytes=32  time=1081ms  TTL=120 
Reply  from  192.168.80.3:  bytes=32  time=1062ms  TTL=120 
Request  timed  out. 

Request  timed  out. 

Ping  statistics  for  192.168.80.3: 

Packets:  Sent  =11,  Received  =  8,  Lost  =  3  (27%  loss), 
Approximate  round  trip  times  in  milli-seconds: 

Minimum  =  1031ms,  Maximum  =  1081ms,  Average  =  765ms 


Figure  76.  PING  TEST  FROM  NOC  TO  MRC  #2 


In  this  testing  evolution,  the  students  were  able  to  show  that  multiple 
technologies  can  be  employed  in  a  WAN  as  long  as  everything  is  IP  based  and  the 
appropriate  routing  schemes  are  employed. 
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III.  FINDINGS  AND  ANALYSIS  OF  EACH  TESTING  EVENT 


A.  FIELD  TEST  #1  (FORT  ORD  AND  BIG  SUR,  CA) 

I.  Findings 

The  findings  discovered  during  this  testing  event  are  discussed  chronologically. 
The  chronological  order  consists  of  testing  with  fSONA  and  Lightpointe’s  FSO  products, 
RF  and  FSO  employed  together,  data  transfer  time  latency  tests,  throughput  analysis 
when  covering  lasers  on  link  head,  and  802.1  lb  with  Linksys  WAP  1  Is. 

During  the  fSONA  free  space  optics  equipment  tests,  a  maximum  throughput  with 
fSONA’s  link  was  roughly  13  Mbps  when  sending  fdes  across  the  network  from  one 
laptop  computer  in  one  local  area  network  (LAN)  to  another  laptop  in  a  second  LAN. 
Although  the  ports  on  the  switches  were  capable  of  100  Mbps,  the  authors  concluded  that 
the  configuration  of  the  routers  and  switches  in  the  network  caused  the  degradation  in 
throughput.  In  a  configuration  where  the  authors  bypassed  the  routers  and  switches, 
going  from  one  laptop  connected  to  the  FSO  link  to  another  laptop  on  the  other  end,  the 
authors  determined  by  using  IPERF  software  that  the  link  could  support  up  to  50  Mbps. 
The  lesson  learned  during  this  phase  of  the  experiment  was  that  the  computer’s  network 
interface  card,  routers,  and  switches  in  both  local  area  networks  would  need  to  be 
configured  at  100  Mbps  full  duplex.  This  configuration  standard  for  both  local  area 
networks  was  therefore  set  for  follow-on  experiments. 

Three  tests  were  conducted  with  Lightpointe  equipment.  One  test  involved 
determining  whether  a  Cisco  2950  switch  was  capable  of  handling  RF  and  FSO 
simultaneously.  Another  test  with  Lightpointe  gear  measured  the  time  latency  of  the 
laser  product  by  transferring  data  files  across  the  network  while  measuring  throughput 
across  the  network.  The  final  test  involved  covering  sectors  on  the  laser  optic  and 
measuring  the  throughput  in  order  to  determine  whether  this  type  of  test  would  be 
beneficial  for  further  testing. 

The  authors  revealed  that  the  Cisco  switch  was  not  able  to  dynamically  switch 
between  RF  and  FSO  while  both  links  were  attached  to  the  switch.  This  Cisco  2950 
switch  was  not  designed  to  accept  two  different  types  of  media.  In  addition,  this 
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particular  switch  was  not  configured  to  take  the  higher  throughput.  After  reconfiguring 
the  switch  to  accept  FSO  only,  the  authors  were  able  to  achieve  10  Mbps  higher  readings 
between  sites.  Furthermore,  the  authors  were  able  to  achieve  a  throughput  of  45  Mbps 
after  doing  a  quick  optimization  of  routers  and  switches.  The  lesson  learned  was  that  the 
equipment  being  used  should  be  configured  to  handle  the  maximum  throughput.  In 
addition,  the  equipment  should  be  configured  for  maximum  throughput  in  the  lab  instead 
of  in  the  field  in  order  to  maximize  experimental  time  in  the  field. 

The  second  test  was  the  time  latency  test.  Data  files  were  transferred  from  one 
local  area  network  to  another  and  the  time  to  transfer  files  across  the  network  was 
measured.  The  results  indicated  that  the  time  annotated  (actual  time  for  the  data  to 
traverse  from  one  network  to  another)  was  not  the  same  as  the  expected  time  for  the  data 
to  traverse  across  the  network.  For  example,  expected  time  to  transfer  a  100  Mbyte  file 
over  a  50  Mbps  link  should  be  2  seconds.  The  reason  for  the  difference  in  time  is  that 
other  factors  are  involved  when  data  is  transferred  from  one  laptop  in  one  local  area 
network  to  another.  Some  of  these  factors  include  the  buffer  size  of  the  receiving  and 
sending  computers  (the  sending  and  receiving  computer’s  buffer  size  temporarily  stores 
the  amount  of  data  that  is  going  to  be  sent);  the  processing  speed  of  the  computer  sending 
or  receiving  the  data;  the  type  of  file  being  transferred;  the  quality  of  service  that  is  taking 
place  within  the  TCP  flow  control  (TCP  uses  a  credit  allocation  scheme);  and  the  time 
delta  (time  delta  is  the  change  in  time  that  it  takes  to  start  the  stop  watch  and  for  the 
actual  time  for  the  experiment  to  start).  The  lesson  learned  was  to  always  be  cognizant  of 
factors  outside  the  scope  of  the  experiment  that  may  affect  the  results  obtained. 

The  third  test  involved  a  measure  of  throughput  while  covering  certain  sectors  of 

Lightpointe’s  link  head.  During  this  test,  sectors  on  the  laser  were  covered  with  a 

cardboard  box.  The  throughput  was  measured  to  see  if  covering  the  laser’s  link  head  had 

any  effect  on  the  throughput.  The  results  indicated  that  the  throughput  remained 

consistent  at  its  maximum  value  (45  Mbps)  regardless  of  the  sector  covered.  Finally,  the 

entire  link  head  was  covered  to  break  its  signal.  It  took  a  20-second  time  interval  to 

reacquire  the  signal  after  the  link  head  was  uncovered.  Twenty  seconds  was  the  time  the 

Cisco  products  needed  in  order  to  recognize  devices  across  the  network,  meaning  the 

laser  product  was  not  the  reason  for  the  delay.  The  lesson  learned  was  that  no  matter  how 
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much  of  the  link  head  was  covered  the  laser  was  still  able  to  transfer  data  between  the 
two  sites  at  the  same  rate  until  the  link  head  was  completely  covered. 

The  last  item  tested  for  the  Big  Sur  experiment  was  802.11b  with  a  Linksys 
Access  Point  (AP-WAP  11).  The  purpose  of  this  experiment  was  to  measure  the 
throughput  of  802.11b  with  yagi  and  parabolic  antennas  (see  Chapter  1  for 
speeifieations).  The  antennas  were  eonnected  to  the  aecess  points,  whieh  were 
configured  in  bridge  mode.  The  results  indieated  that  the  parabolic  antenna  had  better 
results  when  compared  to  the  yagi  antenna.  In  addition,  NetMeeting  was  tested  in  an 
attempt  to  share  files  between  the  two  loeal  area  networks.  It  was  determined  that 
NetMeeting  had  a  maximum  throughput  limit  of  1 .27  Mbps.  The  lesson  learned  was  that 
the  parabolic  antenna  was  capable  of  greater  throughput  over  a  longer  distanee 
(eharacteristies  of  the  antenna).  In  addition,  the  maximum  amount  of  throughput  that  ean 
be  transmitted  when  using  NetMeeting  is  1.27  Mbps. 

2.  Analysis 

The  analysis  for  this  field  test  was  a  straightforward  observation  of  ensuring  that 
the  test  bed  was  eonfigured  for  maximum  throughput.  The  eonfiguration  for  the  test  bed 
items  sueh  as  routers,  switehes,  and  laptops  were  eonfigured  at  full  duplex,  speed  100 
Mbps.  In  addition,  an  understanding  of  equipment  eharacteristies,  sueh  as  TCP  flow 
eontrol  between  computers  and  router  and  switeh  configurations,  were  vital  in  obtaining 
the  results.  Field  Test  One  was  a  basie  “kick  the  tire”  exereise  (familiarization  exercise) 
that  proved  to  be  very  valuable  in  subsequent  experiments. 

B.  FIELD  TEST  #2  (GENERAL  DYNAMICS) 

The  findings  discovered  during  the  General  Dynamies  testing  event  are  discussed 
below.  General  topies  sueh  as  SolarWinds  and  Iperf  differenees  and  throughput  testing 
from  computer  to  computer  are  first  diseussed.  Then,  the  findings  for  following  produets 
are  mentioned:  802. 1  lb  over  SecNet-1 1,  Radio  Frequency  Module  (RFM),  Cisco  Gigabit 
Interface  Cards  (GBICs),  MRV,  Lightpointe,  Ensemble,  Digital  Switch  Unit,  KG-235, 
and  Iridium  Inverse  Multiplexer  (IMUX). 
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1.  Findings 

In  order  to  accurately  measure  the  throughput  of  the  different  technologies  used  to 
connect  the  two  LANs,  the  authors  utilized  programs  called  SolarWinds  and  Iperf  They 
were  significantly  different  in  their  capabilities  since  SolarWinds  is  a  tool  to  measure 
throughput  within  a  network  and  Iperf  is  used  to  generate  data  and  then  measure  the 
throughput.  In  order  to  generate  data  traffic  for  SolarWinds  to  measure  throughput,  the 
authors  used  Windows  file  sharing  between  computers  where  various  types  and  sizes  of 
files  were  sent.  This  type  of  traffic  generation  varied  considerably  from  the  specific  size 
packets  that  Iperf  generated.  Due  to  the  difference  in  traffic  generation  between  the  two 
programs,  each  program  provided  different  throughput  readings.  This  was  done 
intentionally. 

On  another  aspect  of  throughput  testing,  the  authors  noticed  that  sending  data 
from  computer  to  computer  on  different  LANs  was  significantly  slower  than  sending  data 
between  computers  that  were  directly  connected  to  the  link  technology  product,  such  as 
FSO.  The  traffic  generated  within  the  LAN  was  more  realistic  and  thus  was  the  preferred 
choice,  since  it  would  be  rare  to  directly  connect  a  computer  to  the  link  technology 
product. 

The  first  technology  tested  was  802.1  lb  over  SecNet-1 1.  Once  all  the  equipment 
was  set  up  and  data  was  transferred  between  the  two  LANs,  a  noticeable  difference  was 
found  when  transferring  data  from  the  192.168.3.x  network  to  the  192.168.1.x  network 
compared  to  transferring  data  from  the  192.168.1.x  to  192.168.3.x  network.  The 
throughput  from  the  .3  to  the  .1  network  was  1.1  Mbps  and  from  the  .1  to  the  .3  network 
it  was  500  Kbps.  These  tests  were  done  independently  from  one  another,  so  data  was  not 
transferred  both  ways  simultaneously.  The  packet  loss  when  transmitting  data  was  10  to 
15%  throughout  all  the  different  test  readings.  This  was  quite  high  for  a  short  distance  of 
500  meters  and  for  high  gain  antennas. 

Next,  testing  was  conducted  with  a  SecNet-1 1  access  point  placed  in  the  Mobile 
Research  Facility’s  (MRF)  LAN.  The  access  point  was  connected  to  the  Cisco  2950 
switch  via  CAT-5  cable.  Data  was  collected  when  transferring  fdes  between  two  wireless 
laptops  in  the  LAN  associated  with  the  SecNet-11  access  point.  In  addition,  data  was 
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obtained  when  transferring  files  between  one  wireless  computer  associated  with  the 
access  point  and  one  computer  connected  to  the  LAN  switch.  There  was  considerable 
difference  in  the  data  throughput  as  the  wireless-to-wireless  test  produced  a  throughput  of 
2.3  Mbps,  and  the  wireless-to-wired  test  produced  a  throughput  of  4.5  Mbps. 

The  GDDS  RFM  product  came  with  a  Cisco  2950  switch  in  the  carrying  case. 
This  device  interacted  with  the  local  equipment  and  the  established  network.  The  ports 
on  the  switch  were  automatically  set  for  auto-negotiation,  but  an  assumption  can’t  be 
made  that  CAT-5  coming  off  this  switch  can  plug-and-play  with  any  network. 
Consideration  needs  to  be  given  to  the  speed  and  type  of  transmission,  which  need  to  be 
set  on  each  port  in  order  to  successfully  attain  the  highest  throughput  of  the  RFM 
product.  When  the  ports  on  the  RFM  switch  were  not  set  appropriately,  the  average 
throughput  measured  in  Iperf  was  27.4  Mbps.  After  the  ports  were  configured  correctly 
to  match  the  existing  network,  the  throughput  measured  52.3  Mbps. 

When  the  authors  originally  requested  a  temporary  loan  of  Cisco  3745  routers, 
they  requested  GBICs  to  insert  into  the  router  cards,  which  enabled  a  fiber  connection 
from  the  FSO  products.  fSONA  was  the  first  FSO  company  to  set  up  their  product,  so 
they  ran  their  single-mode  fiber  cable  into  the  GBIC  on  the  router.  The  physical 
connection  was  appropriate  as  the  cable  and  port  were  both  Subscription  Channel 
Connector  (SC)  capable.  However,  a  link  light  was  not  showing  on  the  router  card. 
Since  fSONA  uses  a  wavelength  of  1550  nanometers  for  their  lasers  and  single-mode 
fiber  to  come  off  of  the  link  head,  they  needed  a  GBIC  that  supported  a  1310  nanometers 
wavelength  and  the  single-mode  fiber.  As  the  authors  researched  the  Cisco  GBICs,  they 
found  that  they  possessed  only  lOOOBASE-SX  GBICs,  which  accept  a  wavelength  of  850 
nanometers  and  multi-mode  fiber.  This  proved  to  be  the  reason  why  fSONA  could  not 
connect  their  link  head  directly  with  the  network  router  via  a  fiber  cable.  fSONA  needed 
the  Cisco  lOOOBASE-ZX  GBIC.  After  this  failed  connection,  fSONA  used  their  media 
converters  to  connect  to  the  network  with  a  CAT-5  cable  and  experienced  56  Mbps  of 
throughput  measured  by  SolarWinds. 

MRV  Communications  also  utilized  their  own  media  converters  to  convert  their 
FSO  product  to  the  network  router.  Their  product  utilized  the  850  nanometers 
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wavelength  range  but  no  attempts  were  made  to  go  directly  to  the  router  from  their  link 
head.  The  use  of  the  media  converter  enabled  MRV  to  come  off  their  link  head  with  fiber 
cable  and  connect  to  the  router  with  a  CAT-5  cable.  MRV’s  throughput  data  readings 
were  inconsistent  between  15-52  Mbps  on  Iperf,  and  the  media  converter  was  identified 
as  the  possible  problem.  MRV’s  converter  had  certain  settings  that  needed  to  be  set  on 
the  small  dials  located  on  the  side.  After  adjusting  the  settings,  the  data  obtained  showed 
continual  improvement.  However,  the  throughput  was  still  not  quite  right.  Since  time 
was  limited,  MRV  personnel  conducted  further  testing  in  their  labs  after  the  testing  event; 
and  the  results  showed  that  the  media  converters  were  not  set  appropriately  during  the 
testing  event. 

The  next  FSO  company,  Lightpointe,  connected  their  FlightStrata  directly  to  the 
network  routers.  Their  product  used  multi-mode  fiber  cable,  and  it  operated  at  the 
wavelength  of  850  nanometers.  Since  the  GBIC  ports  on  the  routers  were  made  for  this 
exact  type  of  fiber  and  wavelength,  and  an  SC-type  connection  was  used  for  the  link  head 
and  GBIC,  Lightpointe  attained  successful  results  of  80.3  Mbps  on  Iperf  from  the  very 
beginning  of  the  day. 

Ensemble’s  802.16  product  attained  lower  data  throughput  readings  than  the  other 
high  throughput  technologies  such  as  FSO  and  Microwave.  While  Ensemble  promoted 
their  product  at  66  Mbps  of  throughput,  the  actual  capability  when  transmitting  one  way 
was  33  Mbps  and  the  rest  was  reserved  for  traffic  flowing  the  opposite  direction.  Data 
throughput  averaged  10  Mbps,  which  was  low  comparatived  to  other  companies.  Most 
companies  attained  at  least  50%  of  their  link  capability  as  measured  by  SolarWinds  or 
Iperf  One  reason  for  this  slow  speed  was  that  Ensemble  used  a  single-mode  fiber  cable 
to  connect  to  the  GBIC  port  on  the  router.  Fortunately,  the  GBIC  accepted  the  single¬ 
mode  cable,  even  though  the  GBIC  was  designed  for  multi-mode  fiber.  Second, 
Ensemble’s  single-mode  fiber  was  equipped  with  an  ST  connector.  Thus,  an  ST  to  SC 
converter  had  to  be  used  between  the  cable  and  GBIC  port.  On  another  topic,  the  ATM 
configuration  on  the  network  router  for  Ensemble’s  product  proved  to  be  inconvenient 
and  time-consuming.  There  was  no  plug-and-play  capability  like  the  IP  based 
technologies. 
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GDDS  brought  out  their  DSUs  for  this  testing  event.  These  devices  normally 
allow  users  in  the  COC  to  access  any  radio  or  phone  line  that  is  located  on  the  Antenna 
Hill.  While  the  accessing  of  radios  and  phone  lines  was  not  attempted  during  this  testing 
event,  the  ability  to  communicate  VoIP  through  the  DSUs  was  demonstrated.  A  DSU 
and  GDDS’s  laptops  with  the  appropriate  GUI  software  were  connected  to  the  LAN 
switch  on  both  sides  of  the  network  to  enable  this  to  happen.  However,  in  order  to 
accomplish  this,  both  networks  needed  to  be  on  the  same  subnet.  This  was  a  drastic 
change  from  the  three  separate  subnets  utilized  throughout  the  testing.  While  this  was 
beneficial  to  demonstrate,  it  showed  the  current  limitations  of  the  DSU.  Serious 
consideration  needs  to  be  given  to  how  this  can  be  employed  when  COC  to  COC  and/or 
COC  to  Antenna  Hill  communication  is  required. 

As  mentioned  earlier,  VoIP  was  utilized  through  the  DSUs.  It  was  also 
accomplished  through  the  use  of  the  Cisco  IP  phones  in  the  network.  SoIarWinds  read 
the  throughput  of  a  phone  call  at  90  Kbps  no  matter  which  technology  was  employed. 
Although  this  was  not  a  significant  amount  of  bandwidth  utilized  while  employing  high 
throughput  technologies,  it  could  prove  to  be  a  burden  on  the  Marine  Corps’  current 
equipment  such  as  the  MRC-142.  With  the  use  of  multiple  phones  at  the  same  time,  the 
entire  bandwidth  could  be  taken  up  by  voice  only. 

The  KG-235  INE  crypto  devices  used  during  this  event  were  intended  to  bulk 
encrypt  all  traffic  over  the  wireless  link  being  tested,  except  802.11b  with  SecNet-11. 
This  was  done  because  the  technologies  did  not  have  built-in  encryption  techniques.  A 
trained  KG-235  operator  and  the  students  determined  that  since  the  entire  network  was 
set  up  with  three  different  subnets  the  KG-235  could  not  be  placed  between  the  link 
product  and  the  network  router.  The  192.168.2.x  subnet  was  established  on  the  outside  of 
each  router  and  was  the  subnet  of  the  wireless  link  between  the  two  LANs.  The  two  KG- 
235s  needed  to  be  on  separate  subnets  to  function  properly  together.  Therefore,  the 
router  was  eliminated  in  both  networks  and  the  KG-235  replaced  it.  The  KG-235  at  the 
MRF  was  set  as  the  192.168.3.x  subnet  and  the  other  KG-235  was  programmed  for  the 
192. 168.  Lx  subnet.  Unfortunately,  the  fill  on  the  KG-235  at  the  MRF  kept  dropping,  so 
the  configuration  on  the  KG-235  kept  dropping  out.  Thus,  no  connectivity  could  be 
accomplished. 
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Finally,  even  though  the  IMUX  device  used  to  combine  four  Iridium  channels 
was  not  functional  during  the  testing,  the  authors  were  able  to  gain  some  insight  into  how 
the  capability  could  fit  into  the  Marine  Corps  communications  architecture.  Since  the 
four  antennas  sit  on  a  metal  stand  and  connect  to  the  IMUX  box  via  an  RF  cable,  the 
IMUX  did  not  seem  to  be  a  means  of  communication  for  on-the-move.  It  would  have  to 
be  set  up  at  a  company-sized  or  larger  COC.  Special  mounting  options  would  have  to  be 
explored  to  mount  the  antennas  on  vehicles  if  there  was  a  requirement  to  use  it  on-the- 
move.  In  addition,  an  Iridium  phone  must  be  attached  to  the  IMUX  device  in  order  to  use 
one  of  the  channels.  This  is  somewhat  of  an  inconvenience,  but  there  is  an  advantage 
because  while  using  the  phone  others  can  use  the  three  other  channels.  A  compression 
algorithm  such  as  the  one  Dr.  Abousleman  demonstrated  to  the  students  would  need  to  be 
used  with  the  Iridium  service  due  to  its  low  throughput  capabilities. 

2.  Analysis 

The  SolarWinds  and  Iperf  data  varied  considerably  throughout  the  testing  event. 
Iperf  data  always  gave  higher  throughput  readings  due  to  the  consistent  size  of  packets 
being  generated  from  computer  to  computer.  Although  the  SolarWinds  reading  is  a  more 
accurate  depiction  of  how  traffic  will  flow  in  the  tactical  environment  as  various  size 
files,  e-mails,  and  phone  calls  will  be  made,  Iperf  proved  beneficial  because  it  offered  a 
quick  method  to  determine  how  much  throughput  could  be  achieved  with  an  ideal  load 
flooding  the  network  from  computer  to  computer.  However,  this  scenario  does  not 
accurately  depict  the  traffic  flow  in  any  network. 

Another  cause  of  the  lower  throughput  data  when  measuring  it  from  within  the 
LAN  compared  to  computers  directly  attached  to  the  link  is  the  ability  of  the  routers  and 
the  switches.  When  data  is  sent  from  the  computer  within  the  LAN,  the  switch  and  router 
may  experience  traffic  entering  the  device  faster  than  it  can  send  it.  Thus,  significant 
overhead  starts  to  build  on  the  device  and  traffic  in  the  network  is  slowed  down.  When 
the  computers  are  connected  directly  to  the  link,  the  overhead  factor  is  eliminated 
because  there  are  no  switches  and  routers  to  slow  the  traffic.  The  only  limiting  factor  is 
the  computer  capability  to  send  and  receive  data. 

When  transferring  data  between  two  bridges,  the  SecNet-11  equipment  required 

that  one  bridge  be  set  at  ‘Master’  and  the  other  at  ‘Slave’.  The  bridge  at  the  side  of  the 
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192.168.3.x  network  was  set  for  ‘Master’  and  the  other  bridge  at  the  192.168.1.x  network 
side  was  set  for  ‘Slave’.  The  throughput  when  going  from  ‘Master’  bridge  to  ‘Slave’ 
bridge  was  twice  as  large  as  it  was  when  going  from  ‘Slave’  to  ‘Master’.  The  SecNet-1 1 
bridges  are  designed  for  half-duplex  transmission  when  communicating  between  the  two. 
Therefore,  when  setting  a  bridge  configuration  to  ‘Master’,  there  should  be  consideration 
for  where  that  bridge  is  located,  i.e.,  at  a  node  where  most  of  the  traffic  will  be  leaving. 
As  for  the  packet  loss  in  the  bridge-to-bridge  configuration,  the  parabolic  antennas  used 
required  relatively  accurate  pointing  due  to  their  tight  beamwidth  of  eight  degrees.  These 
antennas  were  most  likely  slightly  off  in  their  alignment,  as  the  weather  and  distance 
were  not  a  factor  in  causing  the  packet  loss. 

The  data  collected  for  the  SecNet-11  access  point  showed  that  there  were 
significant  disadvantages  of  going  to  a  completely  wireless  LAN.  The  ability  of  the 
access  point  to  transfer  data  expeditiously  drops  off  as  more  wireless  computers  are  used 
on  the  access  point.  It  may  be  beneficial  to  have  the  users  requiring  wireless  connections 
do  so,  but  the  ones  who  can  stay  near  the  access  point  and  networking  equipment  remain 
wired.  In  addition,  the  computer  wired  to  the  network  does  not  require  a  SecNet-1 1  card 
because  the  traffic  from  the  wireless  computer  to  the  access  point  is  encrypted,  but  the 
access  point  decrypts  the  traffic  prior  to  routing  it  over  the  CAT-5  cable  from  the  access 
point  to  the  switch. 

Since  the  Cisco  switch  provided  with  the  RFM  product  was  set  for  auto¬ 
negotiation,  and  the  network  Cisco  routers  and  switches  were  set  for  speed  100  Mbps  and 
full  duplex,  serious  degradation  in  the  RFM  link  was  apparent.  The  ports  on  the  RFM 
Cisco  switch  need  to  be  configured  the  same  as  the  network  ports.  This  allows  for  a  more 
stable  and  reliable  RFM  link. 

fSONA  needed  a  different  type  of  GBIC  on  the  router  to  directly  connect  their 
single-mode  fiber  from  the  link  head.  Great  lessons  were  learned  about  fiber  connectors. 
First,  the  type  of  fiber  connector  was  important  since  there  are  a  multitude  of  connectors 
and  many  of  them  look  similar.  Next,  the  wavelength  and  type  of  mode  that  a  port,  such 
as  a  GBIC,  supports  was  important  to  identify  early  on.  These  two  important  points  can 
be  easily  overlooked,  but  will  affect  connectivity. 
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MRV’s  media  converter  problems  showed  the  need  of  knowing  the  media 
converter  and  the  proper  settings.  Each  company  came  to  the  testing  event  with  different 
converters,  and  none  were  set  the  same  way.  For  some  reason,  the  MRV  media  converter 
needed  the  dials  on  the  side  of  the  device  to  be  set;  and  most  of  the  other  companies’ 
media  converters  did  not  require  this  type  of  setting.  The  authors  recommend  using  a 
media  converter  that  is  plug-and-play. 

Lightpointe  enjoyed  the  success  of  directly  connecting  their  link  head  to  the 
network  router  with  fiber,  and  they  also  experienced  the  highest  throughput  results  of  all 
the  FSO  companies.  By  eliminating  the  need  for  the  media  converter,  Lightpointe  was 
able  to  avoid  the  change  in  cable  that  the  other  companies  encountered  by  going  from 
fiber  to  CAT-5.  In  order  to  address  the  issue  of  the  different  types  of  GBICs  required,  a 
solution  was  to  have  one  available  for  all  the  different  types  of  fiber  and  wavelengths  on 
hand.  The  GBIC  could  be  easily  switched  out  on  the  Cisco  router.  The  use  of  fiber 
anywhere  in  the  network  would  significantly  increase  the  throughput  capabilities. 

Ensemble  would  have  been  better  served  with  a  proper  single-mode  capable 
GBIC.  While  having  the  different  types  of  interface  converters  on  hand  is  convenient,  a 
media  cross  connect  device  that  connects  all  the  types  of  connections  and  different 
wavelengths  would  be  beneficial.  MRV  Communications  makes  this  type  of  device, 
where  any  type  of  fiber  connection  can  be  added  to  the  device  to  give  a  multitude  of 
options  for  wavelength  and  connector  capabilities.  In  addition,  on  the  same  device, 
copper  and  serial  connections  can  be  added.  Far  too  often,  the  authors  found  themselves 
struggling  with  an  array  of  connections  that  the  different  companies  required. 
Furthermore,  ATM  type  products  required  too  many  configurations  on  the  routers  and 
offered  no  benefit  over  IP  based  products.  Therefore,  the  Marine  Corps  should  adopt  IP 
based  technology.  Ensemble  did  inform  the  authors  that  they  were  developing  an  IP 
based  product.  However,  in  April  the  board  of  directors  for  Ensemble  decided  to  shut  the 
company  down. 

The  DSU  testing  was  a  success  due  to  the  ability  to  talk  via  VoIP  from  the  laptop 
computers.  Since  the  DSUs  are  normally  employed  for  COC  to  Antenna  Hill  scenarios, 
the  VoIP  test  showed  that  operators  in  the  COC  could  talk  to  those  at  Antenna  Hill  as 
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long  as  some  type  of  network  was  set  up  there.  For  example,  the  mode  of  communieation 
between  COC  and  Antenna  Hill  was  via  a  switeh  at  Antenna  Hill.  Then,  the  DSU  and 
computer  connect  to  the  switch  to  form  the  required  network.  This  scenario  could 
realistically  have  users  on  the  same  subnet.  However,  if  communications  were  being 
established  between  two  COCs,  they  most  likely  would  be  on  different  subnets.  In 
conclusion,  the  DSUs  need  to  be  researched  further  to  determine  if  they  can  be  used  when 
communicating  between  separate  subnets.  If  they  cannot,  then  the  UOC  units  will  be 
subject  to  a  ‘flat’  network  across  multiple  sites  in  order  to  employ  VoIP  through  the 
DSU. 

With  the  use  of  VoIP  phones  within  a  network,  the  Marine  Corps  in  the  future 
could  eliminate  the  need  to  employ  switch-based  equipment,  such  as  the  A/N  TTC-42  or 
SB-3865.  This  will  only  happen  though  if  the  Marine  Corps  adopts  some  of  these  higher 
throughput  technologies  to  provide  inter-nodal  communications  because  of  the  amount  of 
bandwidth  required  by  VoIP.  Another  option  is  to  employ  Coder-Decoders  (CODECs) 
that  reduce  the  size  of  the  packets  being  sent  for  VoIP  phone  calls. 

Next,  the  KG-235  acts  as  a  router  but  it  cannot  be  programmed  to  run  specific 
type  of  routing  protocols.  While  the  scenario  for  this  testing  allowed  the  authors  to 
eliminate  the  network  routers  for  the  crypto  devices,  serious  consideration  needs  to  be 
given  to  the  IP  routing  scheme  for  COC  to  COC  connectivity  and  whether  utilizing  a 
routing  protocol  is  important.  The  KG-235  would  be  sufficient  for  establishing  encrypted 
traffic  from  the  COC  to  Antenna  Hill  as  the  local  unit  easily  controls  the  intra-nodal 
communications  IP  scheme. 

Finally,  if  the  IMUX  device  can  be  packaged  in  a  more  effective  manner  for  small 
on  the  move  units,  such  as  platoons,  then  this  device  can  prove  significant.  Battalion  and 
higher  COCs  will  benefit  from  this  device  very  little  if  smaller  sized  units  do  not  have  the 
capability  of  the  Iridium  channels.  The  battalion  or  higher  COCs  do  not  need  this  device 
to  talk  with  higher  headquarters  as  they  will  have  much  higher  throughput  means  to 
communicate. 
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C.  FIELD  TEST  #3  (RAYTHEON) 

1.  Findings 

The  findings  discovered  during  Raytheon  testing  are  discussed  chronologically. 
The  chronological  order  will  consist  of  the  baseline  test,  Lightpointe,  SecNet-11, 
Ensemble,  Terabeam,  In-line  Network  Encryptor  (INE),  Radio  Frequency  Module 
(RFM),  MRV,  MRV-RFM  Switchover,  fSONA,  Voice  over  Internet  Protocol,  Alvarion, 
and  Iridium  Inverse  Multiplexer  (IMUX). 

Lightpointe  was  the  first  company  tested  because  they  were  a  local  company  and 
were  available  to  assist  in  the  baseline  testing.  The  baseline  testing  revealed  it  was  going 
to  be  a  challenge  to  communicate  at  a  distance  of  6.7  kilometers.  The  initial  tests,  data 
transfer  test  (SolarWinds)  and  Iperf,  indicated  about  a  30  Mbps  throughput  across  the 
network.  It  should  be  made  clear  that  SolarWinds  and  Iperf  are  two  diverse  tests  and 
their  applications  are  dissimilar.  SolarWinds  was  a  program  used  to  monitor  throughput 
across  the  network.  Iperf  was  a  program  that  generated  data  across  the  network  and 
displayed  the  results  in  a  text  file.  In  addition,  SmartBits  was  used  to  generate  data 
across  the  network  and  display  the  results  in  a  spreadsheet.  During  the  baseline  testing, 
the  SmartBits  system  changed  the  frame  size  while  keeping  the  throughput  constant. 
This  SmartBits  test  indicated  an  overall  average  frame  loss  percentage  of  4.37.  The 
graphical  representation  of  this  test  is  represented  in  Figure  34  (SMARTBITS 
RAYTHEON  BASELINE  GRAPHICS).  The  other  baseline  product  tested  was  SecNet- 
11.  The  two  tests  conducted  while  using  SecNet-11  were  SolarWinds  and  Iperf. 
SolarWinds  indicated  an  average  throughput  of  1 .64  Mbps  while  Iperf  had  an  average  of 
1.3  Mbps. 

On  February  3,  the  findings  for  Lightpointe  indicated  a  steady  link  with  zero 
percent  packet  loss.  The  average  throughput  for  Lightpointe  while  using  SolarWinds  was 
27.5  Mbps,  and  the  average  throughput  using  Iperf  was  35.8  Mbps.  The  disparity 
between  SolarWinds  and  Iperf  was  due  to  the  type  of  TCP  flow  control  protocols  that  are 
inherent  in  the  TCP/IP  network.  According  to  Douglas  Comer,  flow  control  is  defined  as 
“a  protocol  mechanism  that  allows  a  receiver  to  control  the  rate  at  which  a  sender 
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transmits  data.  Flow  control  makes  it  possible  for  a  receiver  running  on  a  low-speed 
computer  to  accept  data  from  a  high-speed  computer  without  being  overrun.”60 

SolarWinds  demonstrated  a  stop-and-go  flow  control  mechanism  being  used  in 
the  network.  The  stop-and-go  technique  is  an  inefficient  technique  to  pass  data  across  a 
network  because  it  waits  for  an  acknowledgement  from  the  distant  computer  that  the 
distant  computer  is  ready  to  receive  the  transmitted  data.6i  The  throughput  fluctuated 
when  the  type  of  data  (Word,  Power  Point,  Excel,  or  Adobe  documents)  changed  or  the 
size  of  the  file  changed  during  the  transfer  data  test.  It  was  clear  to  see  that  the  stop-and- 
go  technique  was  being  used  between  the  two  computers  in  order  to  prevent  data  overrun 
across  the  network. 

On  the  other  hand,  Iperf  used  what  is  called  a  sliding  window  technique  for  TCP 
flow  control.  According  to  Comer,  “the  sender  and  receiver  are  programmed  to  use  a 
fixed  window  size,  which  is  the  maximum  amount  of  data  that  can  be  sent  before  an 
acknowledgement  arrives. ”62  The  sliding  window  technique  was  observed  with  data 
collected  from  the  Iperf  test.  The  type  of  data  generated  across  the  network  by  Iperf  and 
by  SmartBits  was  clean,  steady,  uniform  data  packets  sent  at  a  uniform  rate;  therefore 
making  it  easier  to  apply  the  sliding  window  technique.  The  SmartBits  data  on 
Lightpointe  revealed  a  throughput  above  30  Mbps  resulted  in  a  frame  packet  loss  of  27.3 
percent.  During  the  SmartBits  test,  the  frame  size  was  kept  constant  and  the  size  of  the 
data  being  transmitted  across  the  network  was  increased  by  increments  of  10  Mbps. 
Executing  the  SmartBits  test  was  extremely  difficult  at  the  beginning  of  the  Raytheon 
test.  The  authors  were  inexperienced  in  operating  the  software  and  the  hardware.  This 
resulted  in  the  test  conducted  during  baseline  testing  being  different  from  the  test 
conducted  on  the  first  day  of  testing. 

On  February  3,  unexpected  low  throughput  was  experienced  over  SecNet-11, 
which  was  not  expected  after  having  an  impressive  day  of  baseline  testing.  Antenna 

60  Douglas  Comer,  “Computer  Networks  and  Internets  with  Internet  Applications”,  (Prentice-Hall  Inc, 
New  Jersey  2001,  third  edition),  pg.  61 1. 

61  Douglas  Comer,  “Computer  Networks  and  Internets  with  Internet  Applications”,  (Prentice-Hall  Inc, 
New  Jersey  2001,  third  edition),  pg.  259 

62  Douglas  Comer,  “Computer  Networks  and  Internets  with  Internet  Applications”,  (Prentice-Hall  Inc, 
New  Jersey  2001,  third  edition),  pg.  259 
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wind  loading  had  a  tremendous  effect  on  the  results.  The  majority  of  the  day  was  spent 
stabilizing  the  antennas  in  order  to  conduct  the  test.  The  distant  end  secured  equipment 
on  their  end  with  guy  wire  in  order  to  prevent  the  antenna  from  swaying.  On  top  of  the 
Raytheon  building,  an  individual  held  the  antenna  and  pointed  the  antenna  in  the 
direction  of  the  distant  end  while  the  test  was  being  conducted.  The  results  from 
SolarWinds  indicated  a  540  Kbps  maximum  throughput.  The  throughput  also  varied 
depending  on  the  type  of  data  being  transmitted.  The  Iperf  test  resulted  in  two  very 
dissimilar  results.  The  first  run  had  an  average  throughput  of  156.9  Kbps  while  the 
second  run  had  an  average  throughput  of  450.2  Kbps.  The  diverse  results  indicate  the 
level  of  trouble  the  testers  had  in  attempting  to  overcome  antenna  wind  loading. 

The  Ensemble  test  resulted  in  observing  that  an  ATM  network  took  time  to 
configure  and  establish.  The  Iperf  data  averaged  around  the  expected  value  of  28.9 
Mbps.  The  throughput  monitored  by  SolarWinds  indicated  an  average  value  of  5.96 
Mbps  with  zero  packet  loss.  The  outcome  of  the  SmartBits  data  was  to  observe  where 
the  maximum  throughput  was  located,  to  determine  where  SolarWinds  was  dropping  the 
link,  to  measure  the  amount  of  packet  loss  when  the  throughput  was  doubled,  and  to 
examine  the  link  with  an  over-saturation  of  data.  The  first  run  indicated  a  maximum 
throughput  somewhere  between  20  and  30  Mbps.  The  second  run  indicated  that 
SolarWinds  was  showing  the  link  down  when  the  link  was  over-saturated  with  data.  The 
problem  was  that  the  link  was  not  down  because  VoIP  was  still  operational  over  the  link 
while  the  over-saturation  was  taking  place.  The  saturation  point  was  somewhere  between 
30  Mbps  and  40  Mbps.  The  data  table  did  not  reveal  the  exact  saturation  point. 
However,  it  did  show  the  packet  loss.  SolarWinds  has  an  upper  threshold  that  if  the 
packet  loss  is  over  30%,  then  the  link  is  identified  as  being  down  (this  was  a  newly  found 
inherent  property  that  was  discovered  during  this  test).  The  data  in  the  table  below  shows 
the  packet  loss  over  30%  at  33  Mbps,  which  is  where  SolarWinds  identified  the  link  as 
being  down  (Table  41). 
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Total 

30 

30 

48756 

37589 

11167 

22.9039 

Data  Group 

N/A 

30 

47800 

36860 

10940 

22.887 

TEST  Group 

N/A 

30 

956 

729 

227 

23.7448 

Total 

31 

31 

50388 

37593 

12795 

25.393 

Data  Group 

N/A 

31 

49400 

36856 

12544 

25.3927 

TEST  Group 

N/A 

31 

988 

737 

251 

25.4049 

Total 

32 

32 

51918 

37524 

14394 

27.7245 

Data  Group 

N/A 

32 

50900 

36788 

14112 

27.725 

TEST  Group 

N/A 

32 

1018 

736 

282 

27.7014 

Total 

33 

33 

53550 

37534 

16016 

29.9085 

Data  Group 

N/A 

33 

52500 

36803 

15697 

29.8991 

TEST  Group 

N/A 

33 

1050 

731 

319 

30.381 

Total 

34 

34 

55182 

37538 

17644 

31.9742 

Data  Group 

N/A 

34 

54100 

36794 

17306 

31.9889 

TEST  Group 

N/A 

34 

1082 

744 

338 

31.2385 

Total 

35 

35 

56814 

37405 

19409 

34.1624 

Data  Group 

N/A 

35 

55700 

36668 

19032 

34.1688 

TEST  Group 

N/A 

35 

1114 

737 

377 

33.842 

Total 

36 

36 

58446 

37552 

20894 

35.7492 

Data  Group 

N/A 

36 

57300 

36806 

20494 

35.7661 

TEST  Group 

N/A 

36 

1146 

746 

400 

34.904 

Total 

37 

37 

60078 

37559 

22519 

37.4829 

Data  Group 

N/A 

37 

58900 

36831 

22069 

37.4686 

TEST  Group 

N/A 

37 

1178 

728 

450 

38.2003 

Total 

38 

38 

61710 

37560 

24150 

39.1347 

Data  Group 

N/A 

38 

60500 

36832 

23668 

39.1207 

TEST  Group 

N/A 

38 

1210 

728 

482 

39.8347 

Total 

39 

39 

63342 

37567 

25775 

40.6918 

Data  Group 

N/A 

39 

62100 

36850 

25250 

40.6602 

TEST  Group 

N/A 

39 

1242 

717 

525 

42.2705 

Total 

40 

40 

64974 

37569 

27405 

42.1784 

Data  Group 

N/A 

40 

63700 

36865 

26835 

42.1272 

TEST  Group 

N/A 

40 

1274 

704 

570 

44.741 

FrameSize 

1518 

Throughput  (%  max  load) 

40 

Frame  Loss  (%) 

42.17841 

Table  41.  ENSEV 

IEEE’S  CONFLICTI 

NG  DATA 

The  third  run  was  conducted  to  measure  the  amount  of  packet  loss  when  the 
throughput  was  doubled.  The  run  revealed  that  when  the  throughput  was  doubled,  the 
packet  loss  increased.  The  data  obtained  from  the  SmartBits  fourth  run  was  an 
exaggeration  of  the  third  run.  The  goal  for  the  fourth  run  was  to  see  the  link  get  over¬ 
saturated  with  data.  The  data  table  below  demonstrates  the  link  getting  over-saturated 
(Table  42). 
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Total 

10 

10 

16218 

16218 

0 

0 

Data  Group 

N/A 

10 

15900 

15900 

0 

0 

TEST  Group 

N/A 

10 

318 

318 

0 

0 

Total 

20 

20 

32436 

32436 

0 

0 

Data  Group 

N/A 

20 

31800 

31800 

0 

0 

TEST  Group 

N/A 

20 

636 

636 

0 

0 

Total 

30 

30 

48756 

37590 

11166 

22.9018 

Data  Group 

N/A 

30 

47800 

36860 

10940 

22.88703 

TEST  Group 

N/A 

30 

956 

730 

226 

23.64017 

Total 

40 

40 

64974 

37568 

27406 

42.17995 

Data  Group 

N/A 

40 

63700 

36850 

26850 

42.15071 

TEST  Group 

N/A 

40 

1274 

718 

556 

43.64207 

Total 

50 

50 

81192 

37545 

43647 

53.75776 

Data  Group 

N/A 

50 

79600 

36758 

42842 

53.82161 

TEST  Group 

N/A 

50 

1592 

787 

805 

50.56533 

Total 

60 

60 

97512 

21164 

76348 

78.296 

Data  Group 

N/A 

60 

95600 

20757 

74843 

78.28766 

TEST  Group 

N/A 

60 

1912 

407 

1505 

78.71339 

Total 

70 

70 

113730 

21161 

92569 

81.39365 

Data  Group 

N/A 

70 

111500 

20741 

90759 

81.39821 

TEST  Group 

N/A 

70 

2230 

420 

1810 

81.16592 

Total 

80 

80 

129948 

21790 

108158 

83.23175 

Data  Group 

N/A 

80 

127400 

21369 

106031 

83.22684 

TEST  Group 

N/A 

80 

2548 

421 

2127 

83.47724 

Total 

90 

90 

146268 

21799 

124469 

85.09654 

Data  Group 

N/A 

90 

143400 

21367 

122033 

85.09972 

Total 

100 

100 

162486 

1452 

161034 

99.10638 

Data  Group 

N/A 

100 

159300 

1422 

157878 

99.10734 

TEST  Group 

N/A 

100 

3186 

30 

3156 

99.05838 

1  FrameSize 

1518 

Throughput  (%  max  loac 

100 

Frame  Loss  (%) 

99.10638 

Table  42.  ENSEMBLE  OVER-SATURATED 


The  testing  for  Terabeam  included  information  about  the  optical  scope,  the  auto 
tracking  feature,  and  the  easy  setup.  The  optical  scope  was  used  to  align  the  two  lasers. 
The  alignment  process  took  a  total  of  five  minutes.  The  auto-tracking  feature 
compensates  for  the  swaying  of  buildings  or  the  movement  of  the  distant  laser.  The  setup 
of  the  Elliptica  was  done  quickly  and  efficiently.  The  findings  provided  the  following 
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insight  when  using  the  Iperf  test:  if  the  window  size  was  too  low,  then  the  data 
throughput  would  result  in  a  lower  value.  For  instance,  the  two  Iperf  runs  below 
demonstrate  different  throughput  results  by  varying  the  window  size  of  the  send  and 
receive  buffers  of  the  computers.  The  data  below  is  a  window  size  of  63  Kbytes: 


Client  connecting  to  192.168.1.2,  TCP  port  5001 
TCP  window  size:  63.0  KByte  (default) 


[928]  local  192.168.3.3  port  1068  connected  with  192.168.1.2  port  5001 

[  ID]  Interval  Transfer  Bandwidth 

[928]  0.0-  5.0  sec  34.0  MBytes  54.3  Mbits/sec 

[928]  5.0-10.0  sec  26.2  MBytes  42.0  Mbits/sec 

[928]  10.0-15.0  sec  27.3  MBytes  43.6  Mbits/sec 

[928]  15.0-20.0  sec  28.0  MBytes  44.8  Mbits/sec 

[928]  0.0-20.0  sec  116  Mbytes  46.2  Mbits/sec 


Now  when  the  data  above  was  compared  to  a  window  size  set  at  0.1  Mbytes,  the 
result  was  a  bigger  throughput  for  the  Iperf  test  (see  below  for  results). 


Server  listening  on  TCP  port  5001 
TCP  window  size:  0.1MByte 


[920]  local  192.168.3.3  port  5001  connected  with  192.168.1.2  port  1059 

[  ID]  Interval  Transfer  Bandwidth 

[920]  0.0- 1.0  sec  8.7  MBytes  69.7  Mbits/sec 

[920]  1.0- 2.0  sec  9.8  MBytes  78.4  Mbits/sec 

[920]  2.0-  3.0  sec  9.7  MBytes  77.4  Mbits/sec 

[920]  3.0-  4.0  sec  10.7  MBytes  85.3  Mbits/sec 

[920]  4.0- 5.0  sec  10.2  MBytes  81.3  Mbits/sec 

[920]  5.0-  6.0  sec  9.5  MBytes  76.3  Mbits/sec 

[920]  6.0- 7.0  sec  10.9  MBytes  88.3  Mbits/sec 

[920]  7.0- 8.0  sec  10.9  MBytes  87.2  Mbits/sec 

[920]  8.0- 9.0  sec  11.3  MBytes  90.2  Mbits/sec 

[920]  9.0-10.0  sec  10.9  MBytes  87.0  Mbits/sec 

[920]  0.0-10.0  sec  10.3  MBytes  82.1  Mbits/sec 
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As  can  be  seen,  adjusting  the  window  size  of  the  data  being  transferred  was  very 
important  when  conducting  the  Iperf  test.  Equally  important  were  the  results  of 
SolarWinds.  This  test  indicated  that  VoIP  and  video  programs  could  run  in  the 
background  while  data  was  transferred  from  one  network  to  another.  The  average 
throughput  while  these  tests  were  conducted  was  16.5  Mbps  and  the  packet  loss  observed 
was  zero.  Two  runs  using  SmartBits  were  conducted.  The  first  run  measured  the  data 
transfer  between  the  two  local  area  networks  while  the  second  run  measured  the  data  and 
VoIP  transfer  across  the  network.  Both  SmartBits  tests  were  measured  to  a  total 
throughput  of  100  Mbps  with  an  incremental  increase  of  10  Mbps.  The  frame  loss  for  the 
data  portion  was  0.33  percent,  while  the  frame  loss  for  the  data  and  VoIP  portion  was 
0.37  percent. 

The  findings  for  the  KG-235  Sectera  In-Line  Network  Encryptors  (INE)  were  that 
the  INE  needed  the  latest  firmware  for  higher  throughput  capabilities  and  the  authors 
were  expecting  a  higher  throughput  result  from  the  product.  When  the  INE  was  tested  at 
Raytheon,  the  INE  had  an  older  version  of  firmware  installed.  The  INE  manufacturer 
specifications  rate  the  product  up  to  17  Mbps  aggregate  data  throughput.63  However, 
upgrades  are  being  done  in  order  to  increase  throughput  to  60  Mbps.  The  maximum 
throughput  observed  for  the  INE  during  testing  was  around  5  Mbps.  The  average  Iperf 
throughput  for  the  two  runs  while  connected  to  the  Terabeam  link  was  3.6  Mbps.  Later 
in  the  week,  the  INE  was  connected  to  the  fSONA  link  and  the  maximum  Iperf 
throughput  was  4.98  Mbps.  While  connected  to  the  Alvarion  link,  a  BLOS  product,  the 
average  Iperf  throughput  was  2.4  Mbps.  When  the  INE  was  connected  to  the  IMUX,  an 
OTH  product,  the  average  Iperf  throughput  was  7.7  Kbps.  Thus,  the  throughput  varied 
depending  on  the  product  providing  the  link  for  the  network. 

The  Radio  Frequency  Module  (RFM)  product  comes  packaged  in  a  hardened  case 
to  withstand  a  rugged  military  environment.  The  product  performed  as  expected  as  a 
series  of  tests  were  conducted  using  an  Iperf  test,  a  data  transfer  test  monitored  by 
SolarWinds,  and  a  SmartBits  test.  The  average  maximum  Iperf  throughput  was  88.2 
Mbps,  and  the  average  maximum  SolarWinds  throughput  was  40  Mbps.  The  SmartBits 

63  http://www.gdc4s.com/Products/secteraspecs.htm 
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test  generated  20  VoIP  phone  eonversations  going  aeross  the  network  along  with  100 
computers  passing  information  simultaneously  across  the  network.  The  test  showed  less 
than  0.23  percent  packet  loss  across  the  network  as  the  load  on  the  network  was  increased 
in  10  Mbps  increments  up  to  100  Mbps. 

The  findings  for  MRV  were  as  expected.  Even  though  the  windy  conditions 
presented  a  problem  on  top  of  the  Raytheon  building,  the  average  maximum  Iperf 
throughput  resulted  in  89.7  Mbps,  and  the  maximum  throughput  recorded  while  using 
SolarWinds  was  59  Mbps.  During  the  SolarWinds  test,  there  were  runs  where  only  data 
was  being  transferred,  there  were  runs  where  VoIP  was  rurming  in  the  background  as  data 
was  being  transferred,  and  there  were  runs  where  VoIP  and  video  clips  were  being  played 
as  the  data  was  being  transferred.  The  SmartBits  test  consisted  of  100  simulated 
computers  sending  data  across  the  network  along  with  20  simulated  phone  conversations 
across  the  network.  The  test  increased  the  throughput  in  10  Mbps  increments  until  the 
link  reached  100  Mbps.  SmartBits  revealed  a  solid  link  with  no  packet  loss  for  the  test. 

The  finding  from  the  MRV-RFM  Switchover,  MRV’s  OptiSwitch,  was  a  seamless 
switchover  between  the  RFM  and  MRV’s  Terescope.  In  order  to  capture  the  hand-off 
from  one  product  to  another,  two  tests  were  run  simultaneously.  The  SmartBits  test 
generated  the  data  across  the  network  while  the  SolarWinds  test  collected  the  nodal 
throughputs  of  the  data  being  transmitted.  The  results  recorded  were  a  54  Mbps 
throughput  when  the  data  was  going  across  the  FSO  link  and  a  33  Mbps  throughput  when 
the  data  was  going  across  the  RFM  link.  The  hand-off  was  a  seamless  transition,  as  the 
user  did  not  notice  a  break  in  the  link.  SmartBits  revealed  a  fifty  percent  packet  loss, 
which  was  expected  because  the  FSO  link  had  to  be  broken  in  order  for  the  RFM  to  pick 
up  the  link. 

The  findings  for  fSONA  were  as  expected.  The  maximum  average  Iperf 
throughput  was  89.13  Mbps.  The  results  from  SolarWinds  showed  a  maximum 
throughput  value  of  53  Mbps.  During  the  SmartBits  test,  fSONA  demonstrated  the 
lowest  frame  loss  percentage  when  compared  to  the  other  FSO  companies.  For  the 
SmartBits  test,  100  computers  were  simulated  passing  data  across  the  network  and  24 
phone  conversations  were  simulated  passing  information  across  the  network.  From  the 
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SmartBits  results,  fSONA  demonstrated  a  frame  loss  pereentage  of  0.0018  percent.  This 
low  frame  loss  percentage  may  be  a  result  of  fSONA’s  laser  being  able  to  produce  a 
power  output  of  640mW,  a  considerable  difference  over  all  other  companies.  fSONA's 
demonstration  of  a  reliable  link  and  of  a  product  that  can  be  integrated  as  a  technical 
solution  for  the  next  generation  of  wireless  technologies  highlights  the  endless 
capabilities  of  wireless  technologies. 

The  findings  for  VoIP  demonstrated  that  quality  of  service  depended  on  how  solid 
the  link  was  between  the  sites,  and  VoIP  remained  operational  across  a  degraded  link. 
Quality  of  service  was  directly  proportional  to  the  quality  of  the  link.  If  the  quality  of  the 
link  was  above  average,  then  the  quality  of  service  for  VoIP  was  the  same.  VoIP  had  a 
unique  quality  that  was  interesting.  Due  to  the  priority  settings  in  the  network  routers, 
voice  was  set  for  the  highest  priority,  so  VoIP  was  able  to  operate  although  the  network 
was  indicating  a  degraded  status.  When  the  quality  of  service  was  degraded,  however, 
the  phone  call  was  still  operational. 

The  findings  for  Alvarion  were  as  expected  for  this  BLOS  product.  The  product 
has  the  capability  of  operating  in  speeds  of  6,  24,  or  54  Mbps.  The  product  was  tested 
with  its  integrated  antenna  and  with  a  larger  external  antenna.  The  distance  of  the  testing 
was  6.7  kilometers  through  a  metropolitan  area  over  to  a  ridgeline.  The  Iperf  throughput 
finding  for  the  integrated  antenna  was  3.0  Mbps.  The  Iperf  throughput  finding  for  the 
external  antenna  was  4.2  Mbps,  and  the  SolarWinds  test  indicated  the  throughput  was 
4.92  Mbps.  The  SmartBits  test  revealed  a  throughput  between  10-15  Mbps,  with 
anything  over  15  Mbps  resulting  in  packet  frame  loss  over  22  percent.  When  tested  with 
the  bulk  encryption,  KG-235,  the  Iperf  throughput  was  2.4  Mbps.  It  is  important  to  point 
out  that  in  order  for  the  authors  to  have  achieved  a  LOS  link  between  the  Raytheon 
building  and  the  ridgeline  on  the  Miramar  base,  the  authors  were  required  to  place  the 
product  being  tested  on  top  of  Raytheon’s  building.  Alvarion’ s  product  was  placed  in 
Raytheon’s  parking  lot,  which  was  not  LOS  to  the  distant  ridgeline. 

The  findings  for  the  Iridium  Inverse  Multiplexer  (IMUX)  resulted  in  an  average 
Iperf  throughput  of  7.7  Kbps.  The  IMUX  has  four  satellite  channels  that  are  capable  of 
passing  2.4  Kbps  on  each  channel,  resulting  in  a  maximum  throughput  of  9.6  Kbps.  The 
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nice  feature  of  the  IMUX  was  that  the  sender  could  place  a  phone  call  while 
simultaneously  transmitting  an  image  across  the  link.  The  compression  algorithm 
observed  in  the  Mobile  Research  Facility  allowed  several  Mbyte  picture  to  be 
compressed  and  sent  over  the  Iridium  link  within  seconds.  In  addition,  the  sender  could 
circle  items  of  interest  on  the  image  that  would  not  get  compressed  in  order  to  enhance 
specific  details  of  the  images. 

The  following  paragraphs  will  discuss  the  Analysis  portion  of  each  product 
chronologically. 

2.  Analysis 

The  analysis  of  the  baseline  test  indicated  lower  throughput  levels  than  expected 
for  the  FSO  product.  Expected  values  of  the  FSO  product  were  to  be  in  the  range  of  80 
Mbps.  The  reason  for  the  lower  levels  might  have  been  due  to  a  FSO  product  being 
introduced  at  a  very  long  distance.  Another  reason  could  be  that  the  baseline  testing  was 
conducted  in  rainy  conditions.  The  rain  might  have  caused  less  than  perfect  conditions 
for  the  beam  of  light  to  traverse  across  to  the  distant  site.  On  the  other  hand,  the 
throughput  levels  for  the  802.1  lb  product  were  higher  than  expected.  The  reason  for  the 
higher  levels  might  have  been  due  to  more  accurate  pointing  of  the  parabolic  antennas. 

The  analysis  of  Lightpointe  testing  resulted  in  throughput  values  lower  than 
expected.  The  authors  can  only  speculate  as  to  the  reason  why  the  maximum  throughput 
was  35.8  Mbps.  The  reason  may  have  been  the  distance  between  sites,  weather 
conditions  that  day,  alignment  of  the  lasers,  interface  between  the  laser  and  the  test  bed, 
or  configuration  of  the  test  bed. 

The  author’s  analysis  of  SecNet-11  testing  resulted  in  a  better  understanding  of 
antenna  wind  loading.  With  a  maximum  throughput  of  540  Kbps,  it  was  obvious  that  a 
directional  antenna  could  deliver  a  bandwidth  that  could  be  beneficial  in  a  tactical 
environment  even  in  adverse  weather  conditions.  In  addition,  SecNet-11  is  a  secure 
National  Security  Agency  (NSA)  Type  1  and  FIPS-140  compliant  encryption  device. 

The  analysis  for  Ensemble  indicated  that  an  ATM  network  took  time  to  configure 
and  establish.  In  addition,  the  ATM  network  handled  the  transfer  of  voice,  data,  and 
video  extremely  well  until  the  link  became  over-saturated.  Ensemble’s  802.16  product 
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provided  a  reliable  link  with  limited  bandwidth  when  eompared  to  FSO.  The  product 
performed  as  expected  with  Iperf,  while  SmartBits  had  greater  throughput  results  than 
SolarWinds.  The  reason  for  the  lower  throughput  in  SolarWinds  was  that  flow  control 
was  being  handled  twice,  once  through  the  ATM  protocols  and  again  through  flow 
control  measures  in  the  computers  sending  and  receiving  the  data. 

The  analysis  for  Terabeam  resulted  in  throughput  values  that  were  expected  from 
an  FSO  product.  The  most  impressive  observations  were  the  optical  scope,  the  auto 
tracking,  and  the  easy  setup.  The  data  collected  was  a  strong  indicator  that  an  FSO 
product  could  be  used  to  connect  different  sub-systems  for  CAC2S.  As  long  as  the  sub¬ 
systems  were  within  line-of-sight,  an  FSO  product  like  Terabeam’s  Elliptica  could  be 
used  to  pass  data  from  one  site  to  another. 

The  analysis  for  the  KG-235  Sectera  In-Line  Network  Encryptors  (INE)  indicate 
that  the  product  has  a  tremendous  potential  for  encrypting  commercial  off-the-shelf 
wireless  products.  The  maximum  throughput  for  the  INE  was  around  5  Mbps.  In  order 
to  produce  a  higher  throughput  from  the  product,  the  authors  discovered  that  the  latest 
version  of  firmware  needed  to  be  installed  on  the  INE.  The  throughput  from  each 
product  was  different.  The  FSO  products  were  able  to  produce  a  higher  throughput 
whereas  the  OTH  product  produced  the  lowest  throughput.  Along  with  the  KG-235, 
other  encryption  devices  provide  bulk  encryption  for  optical  networks.  The  KG- 189 
could  be  used  for  increased  throughput  levels.  According  to  SPA  WAR,  “the  KG- 189 
program  currently  consists  of  models  supporting  three  standard  Synchronous  Optical 
Network  (SONET)  data  rates:  OC-3  model  operates  at  155  Mbps,  OC-12  model  operates 
at  622  Mbps,  and  the  OC-48  model  operates  at  2.5  Gbps.”64  However,  the  author’s 
analysis  revealed  that  the  throughput  was  directly  correlated  to  the  bandwidth  of  the 
product  being  tested.  In  addition,  each  INE  was  assigned  a  different  subnet  in  order  for 
the  two  networks  to  communicate  with  each  other.  In  order  to  pass  information  from  one 
network  to  another,  the  laptops  had  to  be  configured  on  the  same  subnet  as  the  INE. 


64 
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The  analysis  for  the  Radio  Frequeney  Module  (RFM)  resulted  in  throughput 
values  as  expected  from  the  product.  The  field  engineers  were  able  to  configure  the 
switch  (provided  with  the  RFM),  to  speed  100  and  full  duplex.  This  product  would  be  a 
great  fit  for  the  sub-system  connectivity  in  CAC2S. 

The  analysis  for  MRV  resulted  in  values  that  were  expected  from  a  FSO  product. 
MRV’s  Terescope  performed  extremely  well  in  windy  conditions.  The  stability  on  top  of 
Raytheon’s  building  initially  presented  a  problem,  which  was  solved  by  securing  the  laser 
optical  stands.  MRV’s  impressive  reliability  indicated  that  an  FSO  product  could  be 
utilized  in  an  intra-nodal  CAC2S  environment. 

The  analysis  for  MRV’s  OptiSwitch  resulted  in  much  higher  than  expected 
performance.  The  seamless  transition  indicated  that  a  component  such  as  the  MRV’s 
OptiSwitch  can  be  a  vital  element  in  an  architecture  that  requires  multiple  technologies  to 
operate  simultaneously.  In  addition,  a  similar  technology  that  has  both  RF  and  FSO 
embedded,  such  as  MRV’s  Terescope  Fusion,  could  potentially  be  the  solution  for  an 
amalgamation  of  different  technologies. 

The  analysis  for  fSONA  resulted  in  data  throughput  levels  that  were  expected. 
The  power  output  for  fSONA  was  higher  than  the  other  products  tested  which  might  have 
contributed  to  a  lower  frame  loss  percentage  produced  by  fSONA.  fSONA  demonstrated 
that  the  LOS  link  was  capable  of  passing  a  maximum  throughput  in  the  high  80 ’s  with 
outstanding  reliability. 

The  analysis  for  VoIP  indicated  that  the  quality  of  service  is  not  necessarily 
dependent  on  the  quality  of  the  link.  This  is  to  say  that  once  the  link  has  reached  its 
maximum  throughput  level,  the  quality  of  the  phone  call  degraded  to  the  point  of 
dropping  the  call.  Once  the  call  was  dropped,  the  link  was  no  longer  operational.  During 
one  of  the  testing  runs,  the  link  became  degraded  but  the  phone  call  remained  operational. 
The  phone  call  remained  intact  because  of  the  priorities  that  were  established  in  the 
network’s  routers  and  because  the  phone  call  was  placed  over  an  IP  based  network,  VoIP 
link. 

The  analysis  for  Alvarion  indicated  this  type  of  product,  a  BLOS  product,  could 

be  used  in  a  metropolitan  area  for  connectivity.  Alvarion’ s  Orthogonal  Frequency 
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Division  Multiplexing  (OFDM)  product  showed  a  throughput  that  was  capable  of  passing 
through  power  lines,  buildings,  and  trees  over  a  distance  of  6.7  kilometers.  Different 
types  of  antennas  exist  for  this  product.  The  scenario  the  equipment  needed  to  address 
would  determine  the  type  of  equipment  used  for  an  application.  In  addition,  this  product 
was  tested  in  the  Camp  Roberts  experiment  in  March.  The  product’s  testing  in  March 
demonstrated  additional  range  characteristics  and  it  also  demonstrated  communications 
on-the-move. 

The  following  paragraphs  discuss  the  Findings  and  Analysis  of  Field  Test  #4, 
Camp  Roberts  experiment. 


D.  FIELD  TEST  #4  (CAMP  ROBERTS) 

The  following  findings  and  analysis  are  provided  to  help  further  understand  the 
results  of  the  testing  event  conducted  at  Camp  Roberts.  The  following  topics  are  covered 
in  the  respective  order:  Mobile  Access  Router  (MAR),  Cisco  2950  switch  between 
routers,  Cisco  3550  switch,  network  module  on  Cisco  3745  router,  Lightpointe, 
Terabeam,  fSONA,  Linksys  802.11a  access  points,  VoIP,  OFDM,  tethered  balloon, 
UAV,  Segovia/Omega  Systems,  INMARSAT,  Communications  on-the-move,  and  IP 
based  network. 

1.  Findings 

The  students  intended  to  use  the  MAR  as  the  key  piece  of  equipment  at  the  NOC, 
POP,  MRC  #1,  and  MRC  #2.  This  router  is  the  size  of  one’s  hand  and  would  have 
allowed  the  students  to  integrate  multiple  technologies  at  one  location  and  still  effectively 
route  traffic  throughout  the  network.  While  the  cards  of  this  router  are  made  by  Cisco,  a 
company  called  Western  DataCom  integrated  the  cards.  The  main  problem  encountered 
with  the  MAR  was  the  configuration  settings,  which  enable  each  router  to  communicate 
with  one  another.  Despite  the  inability  to  employ  the  router  during  the  testing  event,  LT 
Manny  Cordero  continued  to  pursue  getting  the  router  to  function  properly.  During  an 
NPS  driven  experiment  in  May  at  Camp  Roberts,  CA,  the  MAR  showed  its  usefulness  as 
Western  DataCom  representatives  and  LT  Cordero  finally  put  the  configurations 
together.  The  setup  in  May  was  very  similar  to  the  student’s  testing  in  March.  The  MAR 

worked  much  like  a  Cisco  Call  Manager  where  all  the  phones  communicated  back  to  the 
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server.  For  the  MAR,  a  Home  Agent  was  placed  within  the  network  and  the  rest  of  the 
MARs  throughout  the  network  talked  back  to  the  Home  Agent.  In  May,  the  students 
were  also  able  to  see  the  MAR  automatically  switch  between  two  technologies  when  one 
was  degraded.  These  technologies  were  employed  at  the  same  time  in  a  point-to-point 
scenario.  Furthermore,  the  connections  to  the  MAR  that  performed  Layer  3  functionality 
were  RJ-45  and  smart  serial. 

On  8  March,  the  students  inserted  a  Cisco  2950  switch  between  the  two  routers  at 
the  POP  site.  They  did  this  in  order  to  connect  the  OFDM  and  FSO  links  as  well  as  to 
provide  a  LAN  at  the  POP.  While  this  setup  worked,  it  was  not  the  most  desirable 
configuration.  However,  it  was  the  only  option  for  the  equipment  the  students  had  on- 
hand.  A  computer  connected  to  the  switch  in  the  LAN  was  configured  for  a  gateway  of 
192.168.3.1  to  communicate  with  MRC  #1.  To  talk  with  the  NOC,  the  gateway  was  set 
at  192.168.3.2.  Therefore,  separate  computers  at  the  POP  were  used  to  talk  throughout 
the  network,  or  one  computer  switched  its  gateway  depending  on  the  intended  direction 
of  communication. 

In  order  to  expand  on  the  results  acquired  on  8  March,  the  students  were  able  to 
attain  a  Cisco  3550  switch  on  9  March,  which  was  a  Layer  2/3  capable  device.  This 
enabled  the  students  to  have  one  device  handle  the  functions  that  took  two  routers  and 
one  switch  the  day  prior.  Specific  ports  on  the  3550  switch  were  configured  for  the 
appropriate  IP  address  of  each  subnet.  However,  the  students  were  not  able  to  enter  an  IP 
routing  protocol  into  the  Cisco  Internetwork  Operating  System  (lOS)  for  the  switch.  All 
of  the  other  routers  were  using  EIGRP.  This  meant  that  every  device  in  the  network  that 
had  routing  capabilities  needed  to  be  manually  told  where  to  route.  EIGRP  would  have 
automatically  routed  the  traffic  to  the  appropriate  place  as  it  learned  what  devices  were 
around  it.  The  manual  routing  statements  in  the  Cisco  lOS  worked  properly,  but  the 
students  encountered  problems  getting  to  the  MRC  #1  site  on  that  particular  day.  One  of 
the  problems  could  have  been  the  routing  statement  in  the  Cisco  3550  switch  to  get  to  the 
MRC  #1  site.  Another  problem  could  have  been  from  Segovia’s  satellite  link.  They 
needed  to  tell  their  headquarters  every  IP  address  of  the  routers  and  3550  switch  in  the 
network,  and  how  each  of  these  devices  were  expected  to  route.  A  mistake  could  have 

been  made  when  configuring  the  satellite  settings. 
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On  10  March,  the  students  experimented  with  putting  a  16-port  Ethernet  switch 
network  module  on  the  back  of  the  3745  router,  which  was  located  at  MRC  #1.  The 
intent  was  to  determine  if  the  ports  on  the  module  were  layer  3  capable.  If  so,  this  would 
have  assisted  the  students  in  having  one  device  with  enough  ports  that  could  handle 
802.11b  and  OFDM  links  as  well  as  a  LAN.  Unfortunately,  the  ports  could  not  be 
configured  for  Layer  3. 

On  11  March,  MRC  #1  was  in  a  similar  situation  as  the  POP  site  on  8  March. 
Two  routers  needed  to  be  connected  together  through  a  switch  in  order  to  have  two 
technologies  at  the  site  (802.11b  and  OFDM)  and  a  LAN  off  the  switch.  This 
successfully  worked  as  the  computer  connected  to  the  switch  at  MRC  #1  had  a  default 
gateway  of  192.168.7.2  in  order  to  communicate  with  the  POP  and  NOC.  To  talk  with 
MRC  #2  the  computer  was  set  for  a  default  gateway  of  192.168.7.1. 

Next,  Lightpointe  and  Terabeam  provided  the  two  FSO  links  (March  8-9).  While 
no  data  was  sent  over  the  FSO  link,  data  was  obtained  from  the  NOC  to  MRC  #1  via  the 
POP  site.  Throughput  readings  on  Iperf  showed  throughput  of  4-5  Mbps  on  average. 
The  best  throughput  reading  on  Iperf  between  the  NOC  and  POP  using  OFDM  was  12 
Mbps.  This  data  was  then  routed  through  the  POP  switch  and  through  the  FSO  link  head 
to  another  network.  Based  on  testing  experience,  each  network  setup  drops  the 
throughput  capabilities  of  a  link  by  10  -20%,  which  was  most  likely  the  cause  of  the  drop 
from  12  Mbps  to  4-5  Mbps. 

fSONA’s  product  did  not  establish  connectivity  during  this  testing  event  due  to 
problems  with  the  media  converters.  Reviewing  the  issue  a  week  after  the  testing,  it  was 
realized  that  the  media  converters  that  fSONA  used  at  Camp  Roberts  were  the 
MC102XL's,  which  are  multi-mode  compatible.  These  units  were  NPS-owned  and 
provided  to  fSONA  for  their  use.  At  the  time,  the  students  did  not  know  there  were  two 
types  of  media  converters  (single  and  multi-mode  capable).  The  ones  that  fSONA  used 
in  past  field-testing  events  with  the  SONAbeam-155M  were  MC103XL's,  which  are 
single-mode  compatible  devices.  The  mix  up  of  media  converters  was  the  cause  for  the 
FSO  link  being  down. 


173 


The  students  originally  intended  to  use  the  Linksys  WAP55AG  802.11a  aeeess 
points  in  bridge  mode  to  conduet  point-to-point  eommunications.  However,  after 
attempting  to  eonfigure  them,  the  students  determined  that  this  eould  not  be 
accomplished.  The  Linksys  WAP  11  access  points,  similar  to  the  WAP55AG,  that  were 
used  on  the  balloon  and  UAV  could  be  configured  for  bridge  mode.  Therefore,  the 
students  did  not  expect  to  run  into  this  finding.  Since  the  WAP55AGs  could  not  go  into 
bridge  mode,  the  students  employed  them  in  the  LANs  to  allow  laptops  to  connect 
wirelessly. 

While  using  the  VoIP  telephones,  7960G  and  7940G,  the  students  determined  that 
a  specific  protocol  needed  to  be  used  by  all  the  phones  within  the  network  as  well  as  the 
Call  Manager  server.  The  Cisco  Call  Manager  Skinny  Client  Control  Protocol  (SCCP) 
was  employed  for  this  purpose.  An  example  of  the  differing  protocols  happened  with  the 
7960G  phones  that  were  on  temporary  loan  from  Cisco.  The  two  phones  that  arrived  at 
NPS  were  each  loaded  with  a  different  protocol,  SGCP  and  SIP,  and  they  could  not 
communicate  with  each  other.  Furthermore,  VoIP  calls  were  made  over  the 
Segovia/Omega  Systems  satellite  link,  through  multiple  technologies,  and  through  the 
tethered  balloon.  The  calls  over  the  tethered  balloon  proved  troublesome  since  the  link 
was  unstable.  The  reason  that  a  stable  link  is  needed  is  that  the  phones  throughout  the 
network  need  continuous  contact  with  the  Call  Manager  server. 

The  OFDM  technology  proved  most  impressive  during  this  testing  event. 
Whether  Alvarion  or  Redline  was  using  their  equipment  to  communicate  over  hills, 
through  trees,  or  on  the  move,  the  technology  definitely  proved  reliable.  Since  the  signal 
being  used  was  broken  up  into  multiple  carriers  rather  than  a  single  carrier,  the  chances  of 
getting  connectivity  increased  tremendously.  The  OFDM  technology  equipment  used  by 
Alvarion  and  Redline  is  Layer  2  capable,  thus  an  IP  address  is  assigned  to  either  the 
indoor  unit  for  Alvarion  or  the  AN-50  box  for  Redline.  Furthermore,  the  distance 
capability  of  OFDM  is  out  to  about  20  kilometers  depending  on  the  antenna  used.  The 
students  had  seen  it  work  out  to  10  kilometers  in  a  separate  testing  event. 

The  tethered  balloon  was  one  of  the  platforms  available  during  this  event  to 
provide  retransmitted  communications.  While  working  with  the  balloon,  the  students 
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developed  many  concerns  in  employing  this  platform  in  a  military  environment.  First, 
the  reliability  of  getting  the  balloon  airborne  is  of  question.  The  balloon  could  not  fly  in 
bad  weather  such  as  high  winds  and  heavy  rain.  When  it  was  flying  in  winds  above  10 
knots,  the  balloon  moved  enough  to  cause  significant  packet  loss  of  greater  than  20% 
with  a  directional  antenna  employed  on  the  ground.  This  leads  the  authors  to  recommend 
a  ground-tracking  antenna  be  employed  on  land  to  maintain  connectivity  with  the 
balloon.  Omni-directional  antennas  could  be  an  option,  but  the  gain  on  the  antenna  has  to 
be  enough  to  reach  the  distance.  The  packet  loss  encountered  during  the  testing  was 
enough  to  cause  the  network  to  be  down  for  a  significant  amount  of  time.  Finally,  the 
balloon  caused  air  traffic  control  issues.  The  UAV  had  to  be  deconflicted  with  it  by 
distance  and  time.  If  for  some  reason  the  location  of  a  tethered  balloon  did  not  get  passed 
to  the  air  control  agencies  and  pilots,  there  could  be  serious  problems  with  helicopters 
and  UAVs  flying  through  the  tethered  line. 

While  the  UAV  did  not  meet  its  mission  as  an  airborne  communications  relay  for 
this  testing  event,  a  great  deal  of  learning  occurred  with  airborne  and  ground  antennas. 
First,  the  placement  of  the  antenna  on  the  UAV  needs  to  be  tested  extensively  in  order  to 
obtain  the  best  radiation  pattern  results.  In  addition,  omni-directional  antennas  need 
certain  sized  base  plates  in  order  to  maximize  the  radiation  patterns.  On  the  wooden 
platform  that  was  attached  to  the  UAV,  the  antenna  was  located  on  the  side  of  the  board 
and  it  was  placed  through  the  platform.  This  did  not  allow  for  signals  to  radiate  out  of 
the  antenna  in  an  optimal  manner.  Regardless  of  the  orientation  of  the  antenna,  it  needed 
to  have  a  base  plate  of  the  appropriate  size  for  the  antenna.  Furthermore,  the  antennas  on 
the  ground  need  to  be  either  omni-directional  or  tracking.  The  omni-directional  antenna 
needs  to  have  enough  gain  or  amplification  to  reach  the  UAV.  A  tracking  antenna  will  be 
optimal  as  long  as  GPS  coordinates  could  be  constantly  fed  to  the  antenna  from  the  UAV. 
This  type  of  antenna  allows  for  a  more  directional  beam  to  be  sent  to  the  UAV  antenna. 

The  Segovia/Omega  Systems  team  was  able  to  configure  their  satellite  system  to 

provide  a  satellite  link  within  a  private  network  established  by  the  students.  Segovia  did 

this  by  communicating  to  their  headquarters  the  network  scheme  and  how  traffic  needed 

to  be  routed.  Therefore,  the  students  were  able  to  use  the  airborne  satellite  as  a  relay 

station  between  the  NOC  and  POP.  This  did  not  seem  to  be  a  normal  mission  performed 
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by  Segovia,  since  they  normally  provide  phone  and  Internet  services.  However,  the 
Segovia/Omega  Systems  team  showed  their  diversity  in  the  type  of  services  they  could 
provide  to  their  customer.  The  throughput  they  provided  was  256  Kbps  on  9  March  and 
up  to  1  Mbps  on  March  10-11.  Furthermore,  after  being  exposed  to  their  mounted 
satellite  system  on  the  truck,  Segovia/Omega  Systems  proved  to  be  a  solid  possible 
solution  for  the  CoNDOR  POP  vehicle  satellite  system. 

During  the  testing,  the  students  were  able  to  see  how  well  Nera’s  INMARSAT 
link  performed  on-board  a  moving  vehicle.  The  satellite  antenna  was  very  easy  to  mount 
and  keep  stable  while  employed  on  the  vehicle.  Since  Nera’s  modem  was  unable  to 
interface  with  the  private  network  established  by  the  students,  they  could  not  incorporate 
their  satellite  link  into  the  network.  However,  Nera  did  state  they  could  do  this  with  the 
right  assets.  On  the  other  hand,  Nera  was  able  to  show  the  capabilities  of  their  Internet 
and  phone  services  while  on  the  move.  The  throughput  was  only  64  Kbps,  but  Nera  did 
state  they  are  developing  a  256  Kbps  link. 

Communications  on-the-move  proved  to  be  challenging  for  numerous  reasons. 
For  example,  mounting  the  equipment  onto  the  different  vehicles  created  some  difficult 
scenarios  for  the  research  team.  Wooden  platforms  were  used  to  mount  tripod  stands, 
which  incorporated  OFDM  antennas  and  omni-directional  antennas  for  the  tethered 
balloon  and  UAV.  The  Nera  satellite  terminal  was  also  mounted  on  a  wooden  platform. 
Some  innovative  HMMWV  mounting  options  have  already  been  addressed  in  the  Marine 
Corps  Signals  Intelligence  community.  The  HMMWV  has  a  radar  device  mounted  on 
top  of  the  vehicle  (just  above  the  area  where  the  driver  and  passenger  sit).  A  satellite 
system  could  be  mounted  in  the  same  area.  In  addition,  this  vehicle  has  an  antenna 
mount  that  attaches  to  the  frame  of  the  vehicle  just  next  to  the  passenger  door. 
Implementing  concepts  such  as  these  can  make  communicating  on  the  move  more 
feasible  for  military  personnel. 

This  testing  event  demonstrated  the  advantage  of  an  IP  based  network.  This  type 
of  network  allows  any  IP  based  technology  to  plug-and-play  anywhere  within  the 
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network.  In  addition,  several  technology  methods  were  evaluated  in  this  testing  event  in 
order  to  communicate  BLOS  and  OTH  to  include  OFDM,  the  tethered  balloon,  the  UAV, 
and  Broadband  satellite. 

2.  Analysis 

The  MAR  could  effectively  be  employed  with  any  of  the  programs  studied  in  this 
research:  UOC,  CAC2S,  and  CONDOR.  For  UOC  and  CAC2S,  the  MAR  could  be 
employed  as  a  means  to  route  traffic  in  an  intra-nodal  situation  where  two  wireless 
technologies  are  used  in  a  redundant  manner  between  COC  and  Antenna  Hill  for  the 
UOC  and  between  PDS,  SDS,  and  CS  sites  for  CAC2S.  The  MAR  could  also  be  utilized 
for  inter-nodal  communications  for  UOC  and  CAC2S  nodes  that  displace  quite  often. 
The  units  that  stay  stationary  probably  should  use  regular  network  routers,  such  as  the 
Cisco  3745  used  in  this  testing  experiment.  Furthermore,  the  MAR  would  be  especially 
useful  at  the  CoNDOR  POP  vehicle.  This  site  will  be  managing  multiple  nodes  and 
multiple  technologies.  The  only  dilemma  for  the  MAR  could  be  the  types  of  connections 
from  the  multiple  radios  the  Marine  Corps  uses. 

Despite  the  unfavorable  setup  of  a  switch  between  the  two  routers  at  the  POP,  the 
results  yielded  from  the  8  March  experiment  show  the  diversity  of  a  network 
configuration.  IP  traffic  can  flow  in  a  variety  of  ways  as  long  as  one  has  the  imagination 
to  make  it  happen.  On  the  other  hand,  an  easy  solution  to  this  situation  would  be  to  have 
a  router  that  possesses  a  sufficient  amount  of  Ethernet  ports  for  the  scenario.  For  the 
POP,  the  router  would  have  needed  three  ports:  one  for  the  FSO  link,  one  for  OFDM, 
and  one  for  the  LAN. 

The  author’s  concluded  that  the  Cisco  3550  switch  was  not  the  appropriate  device 
for  the  POP  site  in  order  to  handle  multiple  connections.  Even  though  the  switch  is  Layer 
3  capable,  it  did  not  perform  like  a  regular  Cisco  router.  A  solution  to  the  problem  could 
be  to  use  the  Cisco  3745  router  with  its  two  Fast  Ethernet  ports  that  come  with  the  router. 
In  addition,  a  2FE-2W-V2  network  module  could  be  inserted  into  the  back  of  the  router 
to  give  an  extra  two  Fast  Ethernet  ports.  If  more  ports  are  needed,  the  router  is  capable  of 
receiving  multiple  network  modules  to  provide  the  amount  of  ports  desired. 
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The  16-port  Ethernet  switeh  network  module  used  on  the  router  at  MRC  #1  was 
Layer  2  capable  only.  Thus,  an  IP  address  could  not  be  assigned  to  the  port.  While  it  is 
convenient  to  have  a  router  and  a  switch  on  one  device,  the  cost  of  the  module  is  more 
expensive  than  a  regular  Cisco  2950  24-port  switch. 

Again,  the  Cisco  switch  between  the  routers  at  MRC  #1  on  11  March  was  a 
solution  based  on  availability  of  equipment.  The  easiest  solution  would  have  been  to 
insert  a  two-port  Fast  Ethernet  module  (2FE-2W-V2)  into  the  Cisco  3745  router  to  give 
the  router  four  Fast  Ethernet  ports. 

When  Lightpointe  and  Terabeam  were  set  up  at  MRC  #1,  they  were  providing  a 
link  between  that  site  and  the  POP.  The  test  results  demonstrated  that  the  slowest  link  in 
the  network  dictated  the  data  throughput  of  the  other  links.  Since  OFDM  was  limited  to 
12  Mbps  between  the  NOC  and  POP,  the  FSO  link  between  the  POP  and  MRC  #1  did  not 
speed  up  the  data  transfer  when  communicating  from  the  NOC  to  MRC  #1.  The  data  was 
transferred  at  the  rate  of  the  OFDM  link,  since  the  two  links  were  connected  in  series. 

The  mix-up  with  the  fSONA  media  converters  made  it  evident  to  the  research 
team  that  having  the  correct  media  converter  available  could  determine  whether  a 
positive  or  negative  outcome  could  be  achieved  in  a  testing  experiment.  The  two  types  of 
media  converters  mentioned  in  the  analysis  section  above  looked  exactly  the  same,  so  the 
difference  between  the  two  was  not  evident.  This  was  one  more  reason  why  running 
fiber  cable  between  the  FSO  link  head  and  the  network  router  is  more  beneficial.  The 
other  reason  is  that  throughput  can  be  increased. 

The  WAP55AGs  are  Linksys  products,  a  lower  end  variant  of  Cisco  equipment. 
Neither  Cisco  or  Linksys  access  points  can  do  NSA  certified  Type-1  encryption,  but  they 
can  do  AES  or  Triple  DES  encryption.  A  determination  needs  to  be  made  whether  DoD 
is  willing  to  accept  AES  or  Triple  DES  encryption  within  a  wireless  LAN.  If  so,  then  the 
Cisco  or  Linksys  products  are  viable  options  within  the  LAN. 

Cisco  IP  phones  can  change  protocol  loads,  but  one  phone  cannot  have  more  than 
one  protocol  loaded  onto  it  at  any  given  time.  The  most  appropriate  protocol  for  the 
scenario  needs  to  be  accomplished  prior  to  starting  an  operation.  The  VoIP  phones 

performed  poorly  with  the  25-50%  packet  loss  that  was  being  experienced  through  the 
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tethered  balloon  when  it  was  relaying  802.11b  signals.  If  VoIP  calls  were  made  the 
routing  priority  on  the  network  routers,  the  chance  of  maintaining  the  call  was  much 
greater. 

OFDM  technology  is  a  good  fit  for  UOC  and  CAC2S  in  an  intra-nodal  scenario. 
This  technology  allows  antennas  and  other  communications  equipment  to  be  put  in 
valleys  where  the  gear  can  be  camouflaged  more  effectively.  In  addition,  wires  do  not 
need  to  be  run  over  long  distances.  OFDM  is  also  effective  over  long  distances  for  inter- 
nodal  communications.  Even  if  two  nodes  are  located  outside  the  range  of  a  point-to- 
point  link,  OFDM  can  be  retransmitted  to  increase  the  distance.  The  difference  in 
retransmitting  is  that  there  is  increased  flexibility  of  the  placement  of  the  antenna,  and 
there  is  no  longer  the  need  to  put  it  on  top  of  a  hill.  This  technology  can  also  be  used  in  a 
Military  Operations  in  Urban  Terrain  (MOUT)  environment  since  it  works  around 
buildings.  Furthermore,  OFDM  can  be  used  while  on  the  move.  This  allows  for 
connectivity  within  a  convoy  of  vehicles  that  need  to  exchange  video,  voice,  and  data.  If 
a  UAV  is  flying  overhead  providing  information  to  one  of  the  vehicles  in  the  convoy, 
then  that  vehicle  can  easily  pass  the  information  to  the  others  via  OFDM.  The  convoy 
can  also  maintain  whatever  security  posture  deemed  necessary  because  OFDM 
communications  does  not  limit  the  spacing  of  the  vehicles. 

The  tethered  balloon  cannot  be  relied  on  to  provide  tactical  communications.  It 
presents  security  issues  by  giving  away  friendly  positions,  and  it  is  too  dependent  on 
weather  conditions.  In  addition,  the  logistics  of  getting  helium  bottles  and  a  heavy  launch 
platform  around  the  battlefield  are  key  concerns  in  adapting  this  platform  for  tactical 
communications . 

The  UAV  is  a  more  realistic  method  of  relaying  communications  on  the 
battlefield.  The  platform  used  from  MLB  Company  was  quiet  and  very  hard  to  detect 
while  airborne.  As  long  as  these  platforms  can  remain  stealthy,  they  can  provide  a 
powerful  tool  for  communicators  in  the  Marine  Corps.  With  the  Pioneer  being  the  only 
Marine  Corps  UAV,  there  will  be  major  problems  when  tasking  this  aircraft  for 
communications  missions  rather  than  reconnaissance.  However,  the  platform  can 
perform  a  dual  role  when  applicable  since  an  airborne  communications  payload  could 
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remain  relatively  lightweight.  If  the  Pioneer  was  not  an  option,  the  Marine  Corps  eould 
look  at  future  generation  UAVs  to  be  outfitted  with  a  eommunieations  relay  package  on 
board.  Additionally,  the  Marine  Corps  could  look  at  outfitting  other  aircraft  such  as  the 
C-130  with  an  airborne  relay  package.  The  C-130  that  flies  the  Direct  Air  Support  Center 
missions  can  loiter  over  the  battlefield  for  12  hours  at  a  time. 

For  the  Segovia/Omega  Systems  team,  a  challenge  will  be  how  much  the  services 
will  cost  the  Marine  Corps.  The  advantage  that  Segovia/Omega  Systems  possesses  is  that 
they  have  proven  that  they  can  work  their  satellite  system  into  a  private  Marine  Corps 
battlefield  communications  architecture,  and  they  can  provide  the  required  Internet 
connectivity  for  the  NIPRNET  and  SIPRNET.  If  VoIP  is  implemented  into  the 
communications  architecture,  then  the  Marine  Corps  can  provide  phone  services 
internally  and  they  do  not  need  to  rely  on  Segovia  for  this  service.  Finally, 
Segovia/Omega  Systems  can  be  utilized  in  the  UOC,  CAC2S,  and  CoNDOR 
communications  architecture.  They  have  a  small  footprint,  minimal  power  requirement, 
and  a  powerful  ability  to  provide  broadband  satellite  connectivity. 

With  the  Marine  Corps  command  centers  struggling  to  maintain  connectivity 
while  on  the  move,  Nera’s  INMARSAT  satellite  link  offers  a  possible  viable  solution. 
When  UOC  or  CAC2S  units  send  forward  elements  out,  the  forward  echelon  can  keep 
their  common  operational  picture  up-to-date  which  allows  for  an  easier  and  quicker 
displacement.  One  disadvantage  to  the  INMARSAT  services  is  that  it  is  very  expensive. 
Thus,  further  cost-benefit  analysis  is  needed. 

To  communicate  on  the  move,  vehicles  need  to  be  outfitted  with  the  proper 
mounts  to  place  the  antennas.  OFDM  antennas  can  be  reduced  in  size  to  provide 
connectivity  while  on  the  move.  For  example,  in  May  Redline  offered  to  try  six-inch 
antennas  with  their  equipment  for  a  demonstration  to  Special  Operations  Command. 
Furthermore,  MRC  vehicles  already  have  antenna  locations  on  the  back  of  the  vehicle 
that  can  be  used  while  on  the  move.  Thus,  these  vehicles  could  be  outfitted  with  the 
appropriate  antenna  to  maintain  connectivity  with  an  airborne  relay  platform. 

Overall,  this  testing  evolution  was  conducted  to  show  how  a  CoNDOR 
architecture  could  look  with  currently  available  commercial  technologies.  This  research 
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event  also  directly  applied  to  the  UOC  and  CAC2S  programs  as  they  continue  to  look  for 
innovative  methods  to  communicate  between  and  within  nodes. 
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IV.  CONCLUSIONS 


The  Marine  Corps  is  developing  new  command  and  control  systems  such  as  UOC 
and  CAC2S,  and  new  concepts  for  Marine  Expeditionary  Forces  to  bridge  the  gap 
between  Major  Subordinate  Commands  (MSC)  and  their  subordinate  units.  If  the  Marine 
Corps  continues  to  rely  on  legacy  communications  for  these  programs,  they  could  fall 
short  of  meeting  the  information  needs  of  the  next  war.  New  technologies,  such  as  the 
ones  evaluated  in  this  research  project,  should  be  seriously  considered  to  keep  the 
warfighter  one  step  ahead  of  the  enemy.  The  authors  looked  at  UOC,  CAC2S,  and 
CoNDOR  and  how  to  improve  line-of-sight  (LOS),  beyond  line-of-sight  (BLOS),  and 
over-the-horizon  (OTH)  communications  for  these  programs. 

The  ultimate  goal  of  this  research  project  was  to  introduce  different  technologies 
that  could  offer  more  flexibility,  mobility,  and  capability  at  the  tactical  level  compared  to 
current  legacy  equipment.  These  new  technologies  could  provide  the  Marine  Corps  with 
a  tactical  wireless  edge,  which  could  prove  to  be  essential  in  the  future  combat  missions. 
To  address  the  issues  of  the  UOC,  CAC2S,  and  CoNDOR  programs,  the  authors 
conducted  four  field  tests.  Field  Test  One  was  used  to  familiarize  the  students  with 
networking,  data  collection,  and  develop  interactions  with  commercial  vendors.  Field 
Test  Two  through  Four  then  addressed  the  issues  of  the  different  programs  mentioned 
above.  The  combination  of  all  the  field  tests  enabled  the  authors  to  become  better  suited 
to  draw  the  following  overall  conclusions  for  each  program. 


A.  UOC 

The  planned  intra-nodal  connectivity  between  COC  and  Antenna  Hill  for  the 
UOC  system  will  be  via  fiber  optic  cable.  Furthermore,  the  inter-nodal  communication 
between  UOCs  will  be  via  MRC-142,  satellite  communications,  or  LOS  radios.  The 
inter-nodal  connectivity  needs  to  be  explained  further  due  to  the  different  levels  of  COCs. 
First,  the  battalion  level  COC,  called  CapSet  IV  (see  Chapter  1  for  further  information), 
is  still  relying  upon  LOS  and  UHF  SATCOM  radios  to  talk  to  senior  and  subordinate 
units.  Division  and  regimental  level  COCs,  called  CapSet  II  and  III  (see  Chapter  1  for 
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further  information)  respectively,  are  using  the  MRC-142,  satellite  communications,  and 
LOS  radios  to  communicate  with  senior  and  subordinate  units.  The  Marine  Corps 
understands  the  vulnerabilities  of  relying  on  LOS  radios  and  MRC-142  vehicles  for  data 
and  voice  connectivity.  During  Operation  Iraqi  Freedom  (OIF),  the  Marine  Corps 
regiments  and  divisions  relied  much  more  on  satellite  communications  to  maintain 
connectivity  since  LOS  equipment  was  outran.  Consequently,  alternative  methods  need 
to  be  pursued  instead  of  running  cable  in  intra-nodal  scenarios  and  using  LOS  equipment 
for  inter-nodal  communications.  Several  viable  commercial  technologies  were  examined 
in  this  thesis  that  warrant  further  evaluations  for  UOC  use. 

The  following  technologies  were  examined  for  potential  use  in  the  UOC  intra- 
nodal  scenario  (COC  to  Antenna  Hill):  FSO,  Microwave,  OFDM,  802.16,  and  802.11b 
over  SecNet-ll.  The  FSO,  Microwave,  and  802.16  equipment  evaluated  did  not  have 
any  encryption  built  into  the  products.  Both  OFDM  companies  were  capable  of  limited 
encryption  that  was  built  into  the  equipment.  The  Harris  SecNet-11  gear  utilizing 
802.11b  is  certified  for  Type  1  encryption,  but  the  SecNet-11  testing  did  show  a 
significantly  lower  throughput  than  all  the  other  technologies  (1-2  Mbps).  This  may  be 
enough  to  support  the  battalion  level  (CapSet  IV)  setup,  however  further  testing  needs  to 
be  conducted  to  verify  this. 

When  using  the  KG-235  with  the  FSO,  Microwave,  and  OFDM  products,  the 
throughput  only  reached  up  to  5  Mbps.  However,  this  was  due  to  the  firmware  load  on 
the  KG-235.  The  KG-235  is  capable  of  sending  data  up  to  60  Mbps.  The  authors  were 
unable  to  assess  802.16  with  the  KG-235  due  to  time  limitations.  All  of  these 
technologies  are  viable  wireless  means  in  the  intra-nodal  setup.  The  inherent  problem 
with  using  the  bulk  encryptors  is  the  cost  of  having  to  employ  two  (one  at  each  end)  of 
the  wireless  equipment.  While  units  can  save  time,  be  more  flexible,  and  enjoy  more 
safety,  the  cost  of  the  wireless  equipment  and  encryptors  could  outweigh  the  benefits. 

In  the  inter-nodal  scenario,  CapSet  IV  units  are  planned  to  rely  upon  current  LOS 
radios  such  as  EPLRS  and  SINCGARS  to  exchange  data  with  subordinate  units  when 
UOC  is  fully  fielded.  This  research  did  bring  to  light  many  alternatives  that  can  be 
explored  for  more  effective  communications.  The  Joint  Tactical  Radio  System  (JTRS) 
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will  in  effect  alleviate  some  of  the  current  throughput  limitations,  but  that  program  is  still 
several  years  away  from  being  implemented.  There  is  currently  no  need  for  an  abundant 
amount  of  bandwidth  at  the  lower  levels,  but  the  information  age  has  no  boundaries.  And 
therefore  it  is  ideal  that  units  at  even  the  lowest  level  have  video  and  imagery  capabilities. 
As  a  result,  high  throughput  technologies  that  were  examined  could  be  packaged  more 
appropriately  for  units  on-the-move  and  in  manpack  size  devices  to  provide  the 
throughput  capabilities  to  receive  large  fdes  in  an  expedient  manner.  For  example  in 
LOS  situations,  FSO,  Microwave,  and  OFDM  equipment  can  be  packaged  into  one 
carrying  case  that  can  be  set  up  within  minutes.  OFDM  technology  is  the  most  versatile 
as  it  can  be  used  anywhere  throughout  the  battlefield  in  LOS  and  BLOS  scenarios  and 
with  any  size  units. 

For  CapSet  II  and  III,  the  need  for  equipment  that  can  be  set  up  and  tom  down  in 
an  expedient  manner  became  more  and  more  prevalent  during  OIF.  BLOS  and  OTH 
technologies  mled  the  battlefield  as  units  outran  LOS  communications.  While  most  units 
relied  upon  Blue  Force  Tracker  to  maintain  situational  awareness  on-the-move  and 
SMART-T  for  satellite  connectivity  while  stationary,  this  research  showed  other  options 
available  that  could  significantly  improve  the  abilities  of  units  to  maintain  the  Common 
Operational  Picture  on-the-move  and  exchange  data  more  rapidly  when  communicating 
COC  to  COC.  INMARSAT  showed  its  versatility  and  reliability  while  employed  on-the- 
move.  It  can  attain  throughput  rates  up  to  64  Kbps  with  improvements  possibly  reaching 
256  Kbps.  Broadband  satellite  services  can  reach  almost  five  times  the  throughput  of 
SMART-T’s  capabilities.  However,  the  cost  of  employing  these  technologies  can  be 
expensive,  and  this  may  warrant  a  cost-benefit  analysis  for  future  studies. 

An  alternative  method  to  communicate  between  COCs  is  to  utilize  airborne  assets 
to  retransmit  signals  across  large  distances.  Several  technologies  can  be  used  to 
accomplish  this  task,  yet  the  equipment  and  antenna  need  to  be  small  enough  to  be 
employed  on  the  aircraft.  In  this  research  study,  802.11b  was  retransmitted  and  the 
equipment  was  inherently  small  enough  to  put  in  an  airborne  package.  OFDM  would  be 
a  viable  option  to  put  airborne  but  the  distance  remains  in  question  because  the  signal 
may  not  be  able  to  be  amplified. 
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Due  to  the  security  issues  of  wireless  communications  between  COC  and  Antenna 
Hill,  the  Marine  Corps  may  be  reluctant  to  go  wireless  since  fiber  cable  can  provide  high 
throughput  and  is  a  secure  means  of  transferring  data.  However,  General  Dynamics  is 
recommending  a  technology  insertion  to  the  UOC  program  to  pursue  a  possible  wireless 
connection  between  COC  and  Antenna  Hill.  Next,  the  ability  to  talk  BLOS/OTH  is 
becoming  more  and  more  of  a  priority  for  the  Marine  Corps.  The  UOC  CapSet  II  and  III 
will  benefit  most  from  the  Broadband  satellite,  OFDM,  and  aerial  relays  evaluated  in  this 
research  as  means  to  supplement  or  replace  the  MRC-142  vehicle  for  LOS 
communication  and  SMART-T  for  OTH  situations.  INMARSAT  and  Iridium 
technologies  may  be  the  answer  of  choice  for  communications  on-the-move. 


B.  CAC2S 

The  present  plan  for  CAC2S  is  to  connect  the  intra-nodal  sites  by  heavy-duty 
fiber  optic  cable.  In  order  to  provide  redundancy,  all  the  sites  would  be  connected  with 
fiber  in  a  token-ring  fashion.  However,  the  setup  could  still  be  vulnerable  since  it  relies 
on  the  cumbersome  and  time-consuming  tasks  of  laying  and  burying  wire.  On  the  other 
hand,  fiber  allows  the  transmission  of  secure  data  due  to  the  inherent  security  of  data 
being  contained  within  the  fiber.  As  wireless  technologies  are  studied  for  potential  use  in 
an  intra-nodal  scenario,  decision  makers  need  to  be  aware  that  the  data  is  now  in  the  open 
and  must  be  encrypted  with  a  device  that  is  comparable  to  sending  data  through  the  fiber. 
A  bulk  encryptor  can  accomplish  this,  much  like  the  KG-235  used  in  this  research,  or  the 
wireless  equipment  would  need  security  built  into  it. 

The  following  technologies  were  examined  for  potential  use  in  the  CAC2S  intra- 

nodal  scenario:  FSO,  Microwave,  OFDM,  802.16,  and  802.11b  over  SecNet-11.  FSO, 

Microwave,  and  802.16  equipment  evaluated  did  not  have  encryption  built  into  the 

products.  For  the  OFDM  equipment,  Redline  Communications  has  64-bit  encryption 

built-in  and  Alvarion  is  capable  of  AES  encryption.  NS  A  certifies  the  Harris  SecNet-1 1 

gear  utilizing  802.11b  for  Type  1  encryption,  but  SecNet-11  testing  did  show  a 

significantly  lower  throughput  than  all  the  other  technologies  (1-2  Mbps).  When  using 

the  KG-235  with  the  FSO,  Microwave,  and  OFDM  products,  the  throughput  only  reached 

up  to  5  Mbps.  However,  this  was  due  to  the  firmware  load  on  the  KG-235.  It  is  capable 
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of  reaching  60  Mbps  with  the  right  firmware  load.  Due  to  time  constraints,  the  authors 
were  unable  to  assess  802.16  with  the  KG-235. 

The  current  CAC2S  inter-nodal  structure  uses  a  combination  of  MRC-142  and 
TRC-170  systems.  The  MRC-142  is  strictly  LOS  with  a  maximum  throughput  of  576 
Kbps  and  the  TRC-170  can  extend  out  to  100  miles  with  a  maximum  throughput  of  4.6 
Mbps.  Since  there  are  not  enough  TRC-170s  for  each  node  located  throughout  the 
battlefield,  MRC-142s  are  employed  with  retransmission  sites  set  up  on  top  of  hills  or 
mountains  when  LOS  cannot  be  attained.  The  MRC-142  and  TRC-170  already  employ 
wireless  means  between  sites,  so  the  research  conducted  by  the  authors  looked  for 
wireless  technologies  that  could  significantly  increase  the  throughput  between  CAC2S 
sites  while  also  minimizing  the  physical  footprint. 

Several  technologies  were  looked  at  for  a  CAC2S  inter-nodal  setup  since  there 
can  be  LOS,  BLOS,  and  OTH  requirements  in  this  scenario.  This  all  depends  on  the 
terrain,  location,  and  movement  of  the  CAC2S  units.  The  technologies  examined  were 
FSO,  Microwave,  OFDM,  802.16,  and  802.11b  over  SecNet-11.  Each  of  these 
technologies  was  successfully  tested  at  6.7  kilometers.  FSO  was  more  challenging  to 
align  due  to  the  narrow  laser  beam  transmitted.  Microwave,  OFDM,  802.16,  and  802.1  lb 
over  SecNet-11  (amplified)  demonstrated  the  potential  to  reach  long  distances  if  LOS 
was  maintained. 

When  evaluating  BLOS  technology,  the  authors  reviewed  OFDM.  These 
products  can  reach  out  to  approximately  20  kilometers  in  a  BLOS  scenario,  while 
demonstrating  the  ability  of  communicating  over  hills,  around  buildings,  and  through 
trees.  This  technology  changes  the  dimensions  of  inter-nodal  communications  because 
units  could  possibly  eliminate  the  need  for  a  retransmission  site.  In  addition,  tremendous 
flexibility  on  antenna  placement  is  attained. 

INMARSAT  and  Broadband  satellite  were  evaluated  for  their  OTH  capability. 
INMARSAT  throughput  capability  is  too  small  for  CAC2S  inter-nodal  use,  but  it  could 
be  effective  when  CAC2S  nodes  start  to  displace  and  need  to  maintain  connectivity  on- 
the-move.  The  broadband  satellite  capability  could  reach  up  to  9  Mbps  and  its  footprint 
is  considerably  less  than  the  TRC-170,  so  it  does  have  serious  potential  to  replace  or 
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augment  the  TRC-170  for  use  within  the  CAC2S  arehiteeture.  Both  fNMARSAT  and 
Segovia’s  Broadband  satellite  serviees  are  eapable  of  NSA  Type  1  encryption. 

All  of  these  technologies  (FSO,  Microwave,  OFDM,  802.16,  802.11b  over 
SecNet-1 1,  Broadband  satellite,  and  INMARSAT)  have  a  limited  power  draw  of  less  than 
20  Watts,  which  means  that  the  equipment  can  draw  power  off  a  generator  that  is 
providing  support  to  other  gear.  The  MRC-142  and  TRC-170  always  come  with  their 
own  generators,  thus  making  the  footprint  larger.  While  work  remains  to  be  done  to 
ensure  that  these  wireless  technologies  are  compatible  within  a  military  environment, 
these  commercial  options  improve  throughput,  minimize  footprints,  and  require  less 
power.  All  of  these  characteristics  certainly  would  improve  the  way  CAC2S  deploys  to 
the  field.  Recommendations  for  the  CAC2S  program  can  be  found  in  the  next  chapter. 

C.  CONDOR 

The  problem  inherently  in  the  CoNDOR  setup  is  that  legacy  LOS  radios  and 
eventually  JTRS  are  being  relied  upon  to  provide  data  connectivity  down  to  the  lower 
levels.  These  are  all  limited  in  throughput  capabilities.  For  example  legacy  radios 
provide  less  than  56  Kbps  of  throughput  and  JTRS  is  below  2  Mbps.  While  the  2  Mbps 
throughput  is  sufficient,  JTRS  will  not  be  fielded  until  2008  and  beyond,  and  it  is  an 
unproven  concept.  The  satellite  communications  being  considered  to  connect  the  POP 
vehicle  to  higher  headquarters  is  also  limited  in  throughput  (around  1  Mbps).  Several 
LOS  and  BLOS  technologies  evaluated  in  this  research  are  viable  options  to  connect  the 
CoNDOR  POP  vehicle  to  subordinate  units.  In  addition,  several  technologies  were 
evaluated  to  connect  the  POP  vehicle  to  senior  units  in  a  BLOS  or  OTH  scenario. 

The  CoNDOR  scenario  covers  the  whole  range  of  communication  scenarios, 
LOS,  BLOS,  and  OTH.  Squads,  platoons,  companies,  and  battalions  maneuver  so 
quickly  that  they  could  be  in  any  of  these  communication  situations  within  minutes. 
Thus,  an  integrated  architecture  needs  to  be  adapted  where  all  the  nodes  connecting  to  the 
POP  can  talk  with  each  other,  ensuring  continuous  connectivity  with  the  POP  at  battalion 
headquarters.  This  type  of  architecture  is  currently  very  difficult  to  achieve  with  the 
legacy  radios  employed,  since  all  of  them  currently  rely  upon  LOS.  If  a  communications 
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architecture  can  be  developed  similar  to  Field  Test  Four,  then  units  can  take  advantage  of 
reliable  connectivity  and  increased  throughput  from  the  new  technologies.  This  can  be 
done  while  on-the-move  and  when  traversing  over  hills,  between  buildings,  and  through 
trees.  OFDM  and  airborne  relays  are  two  key  technologies  that  can  transform 
communications  for  ground  units  on  the  battlefield,  since  the  technologies  do  not  require 
stringent  LOS. 

Connectivity  from  the  POP  vehicle  to  higher  headquarters  in  the  CoNDOR 
scenario  will  most  likely  happen  via  satellite,  although  if  close  enough,  BLOS  scenarios 
may  apply.  The  Broadband  satellite  services  by  Segovia/Omega  Systems  should  be 
seriously  considered  for  possible  use  on  the  CoNDOR  POP  vehicle.  The  equipment  can 
be  mounted  on  the  vehicle  and  is  versatile  as  far  as  network  employment.  Private 
network  connection,  Internet,  and  phone  services  can  all  be  provided.  Alternate  means  of 
connectivity  from  the  POP  vehicle  to  higher  headquarters  can  be  achieved  through 
airborne  relay  methods.  The  platform  can  either  relay  directly  between  the  two  sites,  or 
the  platform  can  relay  the  signal  into  space  where  it  can  enter  the  satellite  ring  and  be 
routed  to  any  location  in  the  world.  This  is  a  much  more  complicated  scenario  as  there 
are  several  points  of  failure  in  the  air  as  well  as  on  the  ground.  If  the  POP  vehicle  is 
within  20  kilometers  of  its  higher  headquarter,  most  likely  a  regiment,  then  the  OFDM 
technology  can  be  employed,  eliminating  the  need  for  expensive  satellite  services. 

Many  lessons  can  be  learned  from  OIF  as  the  Marine  Corps  outran  their  LOS 
radios.  As  CONDOR  evolves  and  is  adopted  by  the  Marine  Corps,  those  same  tactical 
radios  that  failed  to  provide  connectivity  in  OIF  may  again  be  insufficient  for  the 
CoNDOR  scenario.  As  the  Marine  Corps  continues  to  find  ways  to  utilize  existing 
equipment,  this  research  opens  doors  to  proven  commercial  off-the-shelf  technologies 
that  the  military  can  further  examine.  If  OFDM  is  packaged  correctly  for  the  appropriate 
sized  units,  then  this  technology  can  truly  integrate  units  and  be  a  reliable  source  to 
connect  to  the  POP  vehicle.  Employing  the  technology  airborne  could  further  enhance 
the  potential  of  ConDOR.  The  price  of  employing  OFDM  is  fairly  reasonable,  but  the 
need  for  encryption  may  drive  up  the  cost.  Whatever  the  cost  may  be,  this  technology 
could  revolutionize  communications  in  the  Marine  Corps. 
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Since  the  use  of  wireless  equipment  introduces  a  potential  security  problem  to 
DoD  infrastructure  networks,  DoD  Directive  8100.2  was  published  on  14  April  2004  to 
address  these  issues.  The  encryption  of  unclassified  data  for  transmission  to  and  from 
wireless  devices  is  required.  Data  encryption  must  be  implemented  end-to-end  over  an 
assured  channel  and  shall  be  validated  to  meet  the  requirements  of  FIPS  PUB  140-1. 
This  applies  to  all  commercial  wireless  devices,  services  and  technologies  including  both 
voice  and  data  capabilities  that  include  commercial  wireless  devices  capable  of  storing, 
processing,  or  transmitting  information.65  Furthermore,  Marine  Administrative 
(MARADMIN)  message  032/2004  was  released  on  23  January  2004  based  on  guidance 
from  the  DoD  Chief  Information  Officer.  This  MARADMIN  stated  that  all  Marine 
Corps  information  technology  developed,  acquired,  or  procured  would  be  IPv6  capable. 
This  is  to  help  the  Marine  Corps  transition  to  IPv6  by  2008  in  order  to  achieve  net-centric 
operations  and  other  warfare  goals.  In  addition,  this  will  help  to  minimize  costs  during 
the  transition  period  from  IPv4  to  IPv6. 66 

Based  on  guidance  from  DoD  Directive  8100.2,  the  need  for  encryption  becomes 
a  serious  concern  as  commercial  technologies  are  embraced  by  the  military.  Since  most 
commercial  off  the  shelf  technologies  are  not  equipped  with  Type  1  encryption,  separate 
devices  need  to  be  used  to  encrypt  the  traffic  going  through  commercial  devices.  This 
raises  the  costs  of  procuring  new  equipment,  so  a  cost-benefit  analysis  needs  to  be  done 
to  determine  if  the  capabilities  of  the  gear  compared  to  legacy  equipment  outweigh  the 
costs  of  procuring  the  gear.  Some  of  the  companies  do  have  encryption  techniques  built 
into  their  products  such  as  AES,  but  further  analysis  needs  to  be  done  to  verify  that  this 
meets  the  standard  to  transmit  classified  traffic.  Overall,  a  requirement  could  be  given  to 
a  commercial  company  to  pursue  building  Type  1  encryption  into  their  products.  In  turn, 
this  could  significantly  raise  the  cost. 

As  seen  in  MARADMIN  032/2004,  Marine  Corps  networks  will  follow  the  IPv6 
standard  by  2008.  This  reinforces  why  the  students  chose  to  demonstrate  a  fully  IP  based 
network  in  all  testing  events.  The  UOC  and  CAC2S  programs  are  also  pursuing  IP  based 

65  DoD  Directive  8100.2,  “Use  of  Commercial  Wireless  Devices,  Services,  and  Technologies  in  the 
Department  of  Defense  (DoD)  Global  Information  Grid  (GIG)”,  14  April  2004. 

66  MarAdmin  032/2004,  “Marine  Corps  Internet  Protocol  Version  6  (IPv6)  Policy”,  23  January  2004. 


190 


networks  for  their  systems.  There  are  numerous  benefits  of  being  IP  based  that  the 
students  identified  during  this  research.  First,  voice,  video,  and  data  can  all  be  sent  over 
this  one  protocol.  This  ensures  a  common  standard  across  the  network  in  which 
information  can  be  easily  shared  among  all  users.  During  Field  Test  Four,  the  students 
were  able  to  demonstrate  multiple  technologies  across  eight  subnets.  These  technologies 
were  compatible  as  long  as  the  equipment  supported  an  IP  network.  This  allowed  for  a 
tremendous  amount  of  flexibility  for  new  technologies  that  could  be  interfaced  in  a 
CoNDOR  scenario.  In  addition,  if  the  UOC  and  CAC2S  use  VoIP  phones  and  laptops  to 
move  away  from  switch-based  equipment  for  telephones,  a  much  smaller  footprint  for 
each  node  would  be  required.  Furthermore,  CoNDOR  will  benefit  tremendously  if  every 
device  used  to  transfer  data  can  be  assigned  an  IP  address. 

In  conclusion,  the  authors  introduce  different  technologies  that  offer  more 
flexibility,  mobility,  and  capability  for  communications  on  the  tactical  battlefield. 
Throughout  this  research  study,  the  focus  revolved  around  testing  equipment  and  network 
configurations  in  an  IP  network  in  order  to  demonstrate  a  tactical  wireless  edge.  Special 
consideration  was  given  to  wireless  issues  for  the  UOC,  CAC2S,  and  CoNDOR,  which 
could  improve  line-of-sight,  beyond  line-of- sight,  and  over-the-horizon  communications 
for  each  program.  These  new  technologies  will  transform  communications  in  the  United 
States  Marine  Corps  for  the  21®'  century. 
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V.  RECOMMENDATIONS  FOR  UOC,  CAC2S,  AND  CONDOR 


A.  WHAT  CAN  BE  IMPLEMENTED  NOW 

Initial  guidance  from  Marine  Corps  Systems  Command  was  to  examine 
technologies  that  could  be  implemented  into  UOC,  CAC2S,  and  CoNDOR  ‘now’  as  well 
as  in  the  future.  For  the  ‘now’  portion  of  the  write-up,  the  authors  decided  to  combine 
the  UOC  and  CAC2S  reeommendations  sinee  the  eommand  and  control  systems  have 
similar  distance  requirements  when  physically  deployed  on  the  battlefield  and  the 
requirements  for  eommunications  on-the-move  are  also  very  mueh  alike.  CoNDOR’ s 
reeommendations  were  kept  separate  sinee  it  is  not  a  eommand  and  eontrol  system  but 
rather  a  coneept  of  eonnecting  multiple  echelons  of  command  together.  Table  43  below 
is  a  quick  reference  guide  summary  of  recommendations  for  the  three  programs.  For 
UOC  and  CAC2S,  there  are  four  functional  areas  that  communications  requirements  ean 
fall  under:  intra-nodal,  inter-nodal,  eommunications  on-the-move,  and  aerial  relay.  The 
CoNDOR  coneept  revolves  around  the  Point  of  Presenee  Vehiele  (POP-V)  so  the 
funetional  areas  were  outlined  as  follows:  into  POP-V,  out  of  POP-V,  communications 
on-the-move,  and  aerial  relay. 

The  ranking  system  used  to  prioritize  the  recommendations  for  eaeh  type  of 
category  (line-of-sight  (LOS),  beyond  line-of-sight  (BLOS),  and  over-the-horizon 
(OTH))  within  the  physical  structure  breakdown  of  the  programs  is  straightforward.  The 
number  “one”  depiets  the  first  reeommendation  out  of  all  the  technologies.  Eaeh 
subsequent  number  up  to  five  delineates  the  second,  third,  fourth,  and  fifth 
recommendations.  Ranks  were  assigned  subjeetively  by  the  authors  based  on  the  results 
of  the  tests,  the  requirements  of  the  systems,  and  the  author’s  experienee. 
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Table  43 .  UOC,  CAC2S,  AND  CONDOR  RECOMMENDATIONS 


1.  UOC/CAC2S 

a.  Intra-Nodal 

By  utilizing  wireless  technologies  to  link  a  Command  Center  to  Antenna 
Hill  within  a  UOC  node  or  from  Processing  and  Display  Subsystem  (PDS)  to 
Communications  Subsystem  (CS)  and  Sensor  Data  Subsystem  (SDS)  in  a  CAC2S  node, 
the  Marine  Corps  could  potentially  replace  fiber  cables  that  run  between  the  sites.  This 
will  enable  a  quicker  setup  and  tear  down  of  equipment,  which  would  then  enable  a  unit 
to  be  more  flexible  and  mobile.  In  addition,  the  possibility  of  cables  being  damaged  by 
vehicles  and  equipment  would  be  eliminated,  and  Marines  would  not  have  to  spend  time 
digging  trenches  to  bury  fiber  cable  as  they  do  now. 

The  intra-nodal  setup  is  divided  into  two  different  categories  for 

communications,  LOS  and  BLOS.  While  antennas  will  most  likely  sit  in  some  type  of 
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defilade,  the  wireless  communications  equipment  could  be  easily  placed  on  top  of  the  hill 
to  obtain  LOS  with  the  COC  or  PDS  for  UOC  and  CAC2S  respectively.  Since  another 
technology  was  explored  in  this  research  that  would  allow  connectivity  to  be  established 
while  the  two  antennas  were  not  in  sight  of  each  other,  there  is  the  BLOS  connectivity 
recommendation  for  the  intra-nodal  scenario. 

The  LOS  technologies  researched  for  the  intra-nodal  setup  in  the  order  of 
recommendation  are  as  follows:  Free  Space  Optics  (FSO),  Microwave,  Orthogonal 
Frequency  Division  Multiplexing  (OFDM),  802.16,  and  802.1  lb  over  SecNet-1 1.  FSO  is 
the  right  fit  for  a  short  distance  of  less  than  2  kilometers.  There  are  various  benefits  to 
using  this  technology:  throughput  comparable  to  fiber  cable  speeds,  operates  in  a  license 
free  spectrum,  enjoys  a  quick  set  up  and  tear  down  time,  and  is  not  as  susceptible  to 
weather  at  a  short  distance.  While  the  Microwave  product,  Radio  Frequency  Module, 
examined  for  this  thesis  had  comparable  characteristics  to  the  FSO  product  with  better 
distance  capabilities  and  less  vulnerability  to  atmospheric  conditions,  it  required  a  license 
to  operate  in  the  14-15  GHz  range.  This  would  not  be  an  issue  during  a  time  of  war,  but 
when  training  with  it  throughout  the  world  there  could  be  problems  obtaining  frequency 
use.  In  addition,  the  transmitting  beamwidth  is  much  greater  than  FSO;  therefore, 
making  microwaves  more  susceptible  to  interception.  Next,  OFDM  and  802.16  have  less 
throughput  capability  than  FSO  and  Microwave.  OFDM  can  operate  in  the  5  GHz 
license  free  spectrum  and  has  limited  built  in  encryption,  while  802.16  requires  a 
frequency  license  to  operate  the  equipment.  Finally,  802.11b  over  SecNet-11  has  a 
powerful  capability  of  National  Security  Agency  (NS  A)  certified  Type  1  encryption  built 
into  the  cards.  Therefore,  no  external  encryption  device  would  is  needed  to  utilize  this 
equipment.  The  downside  of  the  SecNet-1 1  equipment  is  that  the  throughput  of  802.1  lb 
is  severely  limited  compared  to  the  other  broadband  technologies.  The  1-5  Mbps  attained 
would  not  be  enough  to  replace  a  cable  run  between  sites,  which  can  currently  run  at 
gigabit  speeds. 

OFDM  was  examined  and  evaluated  throughout  this  thesis  research  at 

various  field  tests.  OFDM  has  a  distinct  advantage  of  being  placed  in  valleys  near 

Antenna  Hill,  where  it  can  be  camouflaged  without  inhibiting  the  capacity  of  the  link. 

The  throughput  of  the  technology  can  vary  considerably,  but  it  is  capable  of  reaching  up 

195 


to  72  Mbps.  The  authors  only  saw  throughput  up  to  24  Mbps,  however,  when  in  non- 
line-of-sight  situations.  A  significant  benefit  of  this  equipment  is  that  it  is  small  and 
requires  minimal  power.  The  20-30  Mbps  range  would  be  sufficient  to  support  the  link 
between  Command  Center  and  Antenna  Hill  for  the  UOC  and  CAC2S.  Even  though  this 
was  the  only  technology  examined  for  BLOS  situations,  no  other  technologies  are  known 
that  can  offer  this  type  of  flexibility  unless  satellite  communications  are  employed.  The 
use  of  satellites  would  not  be  practical  for  the  intra-nodal  scenario.  Therefore,  OFDM  is 
the  only  recommended  BLOS  technology  for  both  UOC  and  CAC2S  in  the  intra-nodal 
setup. 

b.  Inter-Nodal 

The  UOC  program  will  continue  to  utilize  legacy  systems  to  provide 
connectivity  between  UOC  nodes  located  throughout  the  battlefield.  At  the  regiment,  the 
MRC-142  vehicle  can  provide  LOS  connectivity.  Below  the  regiment  level,  tactical 
radios  such  as  Enhanced  Position  Location  Reporting  System  (EPLRS)  and  Single 
Channel  Ground-Air  Radio  System  (SINCGARS)  will  continue  to  be  utilized  until  the 
Joint  Tactical  Radio  System  (JTRS)  is  fielded.  At  the  regiment,  for  BLOS  and  OTH 
capability.  Secure,  Mobile,  Anti-Jam,  Reliable  Tactical  Terminal  (SMART-T)  will  be 
employed  as  well  as  receive  only  Global  Broadcasting  Service.  There  is  currently  no 
BLOS/OTH  capability  below  the  regiment  except  for  PSC-5  UHF  SATCOM  radios. 
Next,  CAC2S  will  rely  on  two  primary  methods  of  transmitting  data  between  nodes  on 
the  battlefield,  MRC-142  and  TRC-170.  Despite  their  capabilities,  these  legacy  systems 
have  some  shortfalls.  The  MRC-142  has  limited  bandwidth  with  LOS  distance 
capabilities  of  up  to  35  miles,  and  the  TRC-170  has  a  major  footprint  to  go  along  with  a 
significant  power  requirement.  The  technologies  examined  can  provide  significant 
improvement  in  throughput,  a  smaller  footprint,  and  a  smaller  power  requirement  over 
the  legacy  equipment  planned  for  employment  with  UOC  and  CAC2S  systems. 

Since  the  distances  between  UOC  and  CAC2S  nodes  are  unpredictable 
due  to  the  frequent  movement  of  units  on  the  battlefield,  the  three  communications 
scenarios,  LOS,  BLOS,  and  OTH,  could  all  be  encountered  at  any  given  time.  The  LOS 
scenario  is  rated  quite  different  that  the  LOS  setup  for  intra-nodal  communications.  In 
order  of  ranking,  the  following  technologies  are  recommended  for  use  in  LOS  situations 
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for  the  inter-nodal  scenario:  OFDM,  802.16,  Microwave,  FSO,  and  802.11b  over 
SecNet-1 1.  When  LOS  can  be  attained  between  two  UOC/CAC2S  nodes,  it  is  likely  the 
distance  will  be  greater  than  5  kilometers  and  the  terrain  will  not  be  perfectly  flat. 
OFDM  is  best  suited  for  this  type  of  setup  since  it  is  the  most  forgiving  of  the 
technologies  if  ideal  LOS  is  not  attained.  The  reason  to  recommend  802.16  technology 
over  Microwave  is  that  802.16  can  reach  out  to  20  kilometers  while  the  high  throughput 
microwave  is  limited  to  13  kilometers.  Next,  FSO  is  designed  for  distances  of  less  than 
five  kilometers.  While  it  was  shown  to  function  up  to  seven  kilometers  and  most  likely 
further  than  that  with  ideal  weather  conditions,  bad  weather  would  reduce  the  quality  of 
communications  obtained  at  further  distances.  802.11b  over  SecNet-11  is  recommended 
last  because  of  its  low  throughput  as  distances  increase,  and  it  is  vulnerable  to  denial  of 
service  since  it  operates  in  the  well  known  2.4  GHz  range. 

OFDM  can  operate  in  LOS  or  BLOS  situations.  This  makes  the 
technology  the  number  one  recommendation  for  inter-nodal  BLOS  scenarios.  OFDM  can 
maintain  connectivity  over  hills,  through  trees,  and  around  buildings.  In  addition,  the 
cost  to  purchase  the  equipment  is  under  $5k,  which  makes  it  relatively  inexpensive.  No 
other  technologies  were  examined  that  could  provide  terrestrial  BLOS  connectivity; 
therefore,  satellite  connectivity  was  rated  against  OFDM  in  the  BLOS  category.  The 
second,  third,  and  fourth  recommendations  are  as  follows:  Broadband  satellite, 
INMARSAT,  and  Iridium  respectively.  These  are  also  in  the  same  order  for  OTH 
communications  in  the  inter-nodal  scenario.  Broadband  satellite  provided  by 
Segovia/Omega  Systems  can  replace  the  TRC-170  setup  for  CAC2S  with  its  capabilities 
to  reach  up  to  9  Mbps,  and  it  is  comparable  in  size  with  the  SMART-T  system  but  could 
provide  more  throughput  capability  for  the  UOC  node.  INMARSAT  and  Iridium  are 
ranked  lower  because  the  throughput  capabilities  for  the  inter-nodal  setup  are  insufficient 
to  support  the  requirement  for  the  nodes.  INMARSAT  is  also  much  more  expensive  than 
Broadband  satellite.  These  two  technologies  will  be  discussed  in  the  communications  on- 
the-move  section  when  they  are  more  applicable. 
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c.  Communications  on-the-Move 

Communications  on-the-move  can  no  longer  be  overlooked  for  the  UOC 
and  CAC2S  nodes  since  forward  echelons  must  be  sent  out  when  displacing.  This 
forward  echelon  is  used  to  taking  control  when  the  main  node  begins  to  displace.  While 
the  forward  echelon  is  displacing,  they  need  to  keep  situational  awareness  to  assist  in  the 
turnover  from  main  to  forward.  This  situational  awareness  usually  comes  in  a  digital 
format.  So,  if  connectivity  is  lost  then  vital  time  could  be  wasted  trying  to  pass  updates 
from  the  main  to  the  forward  echelon.  Communications  on-the-move  is  broken  down 
into  three  categories  which  are  listed  as  follows:  within  the  convoy,  outside  the  convoy, 
and  short/long  halts. 

(1)  Within  the  Convoy.  The  communications  that  are  utilized 
within  the  convoy  link  all  the  vehicles  together  to  exchange  information.  One  vehicle 
within  the  convoy  will  maintain  connectivity  with  other  units  outside  the  convoy.  Single¬ 
channel  voice  communications  are  currently  maintained  but  data  connectivity  is  quite 
limited.  If  a  limited  network  is  set  up  within  each  vehicle,  and  each  is  outfitted  with  the 
appropriate  antennas,  then  the  whole  convoy  can  maintain  high  throughput  connectivity 
via  OFDM  or  802.11b  over  SecNet-11.  OFDM  has  the  highest  recommendation  since 
LOS  does  not  need  to  be  maintained  while  the  vehicles  are  moving.  Each  vehicle  can 
remain  a  safe  distance  away  from  the  others,  which  ensures  a  good  security  posture.  The 
OFDM  technology  can  connect  the  convoy  by  placing  a  sector  antenna  in  the  lead  vehicle 
while  all  others  maintain  an  omni-directional  antenna  (other  options  could  be  employed). 
802.11b  over  SecNet-11  can  work  as  long  as  LOS  is  sustained  while  the  vehicles  are  in 
motion.  Most  likely  omni-directional  antennas  and  amplifiers  would  need  to  be  utilized 
for  this  purpose.  The  cost  for  both  of  these  setups  would  be  very  similar. 

(2)  Outside  the  Convoy.  While  the  distance  and  terrain  can  vary 
greatly  when  communicating  from  a  forward  echelon  convoy  back  to  the  main,  some  type 
of  satellite  connectivity  that  can  function  on-the-move  would  be  needed.  INMARSAT 
and  Iridium  were  examined  for  this  capability.  INMARSAT’S  throughput  capabilities  are 
far  superior  to  the  limited  throughput  of  Iridium.  Therefore,  INMARSAT  is 
recommended  over  Iridium  despite  the  lower  cost  of  Iridium.  If  within  a  10-20  kilometer 
radius,  the  convoy  could  maintain  connectivity  with  the  main  terrestrially  through  the  use 
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of  OFDM.  The  antennas  on  the  vehicle  and  with  the  main  would  need  to  be  omni¬ 
directional,  which  would  decrease  the  distance  OFDM  could  operate.  OFDM  is  the  last 
recommendation  due  to  the  distance  limitation,  but  it  is  still  an  option  since  terrain 
becomes  less  of  an  issue  with  this  technology. 

(3)  For  Short/Long  Halts.  While  communications  on-the-move  is 
vital,  it  is  also  important  to  recognize  that  there  may  be  times  when  short  or  long  halts  of 
a  convoy  are  needed.  Thus,  some  type  of  quick  setup  is  needed  for  connectivity  from  the 
forward  echelon  to  the  main.  The  communications  within  the  convoy  can  stay  per  the 
recommendations  earlier,  as  vehicles  can  maintain  an  effective  security  posture  and  stay 
BLOS  from  each  other.  If  the  convoy  was  using  INMARSAT  as  the  communications 
connectivity  for  on-the-move,  then  this  may  remain  sufficient  for  a  short  halt.  However, 
during  a  lengthy  halt,  it  may  prove  useful  to  set  up  Broadband  satellite  connectivity  for 
more  throughput  capability.  The  Segovia/Omega  Systems  equipment  can  self-acquire  the 
aerial  satellite;  therefore,  connectivity  could  be  established  within  minutes. 
d.  Aerial  Relay 

The  use  of  aerial  relays  for  UOC  and  CAC2S  nodes  can  greatly  increase 
inter-nodal  communications.  This  could  be  an  alternative  to  the  MRC-142  or  TRC-170, 
as  the  802. 1  lb  over  SecNet-1 1  could  be  retransmitted  via  the  aerial  platform  for  hundreds 
of  miles  if  the  signal  was  amplified  and  appropriate  antennas  were  utilized.  If  it  is 
determined  that  OFDM  can  be  amplified,  then  distance  could  equal  that  of  802.11b  and 
greater  flexibility  is  attained  on  where  antennas  would  need  to  be  placed  on  the  ground  to 
maintain  connectivity  with  the  aerial  platform.  Since  802.1  lb  was  tested  and  has  proven 
to  work  over  great  distances,  this  technology  is  the  first  recommendation.  More  research 
needs  to  be  conducted  with  OFDM  to  determine  the  validity  of  using  it  as  a  technology  in 
an  aerial  relay  platform. 

2.  CONDOR 

a.  Into  POP-V 

The  current  plan  for  the  CoNDOR  scenario  is  to  place  a  Point  of  Presence 
Vehicle  (POP-V)  at  the  battalion  level  to  further  enhance  the  capabilities  of  the 
subordinate  units  with  low  throughput  capabilities.  This  vehicle  will  allow  those  units 
with  EPLRS,  SINCGARS,  HF,  HF  Automatic  Link  Establishment  (ALE),  and  UHF 
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SATCOM  to  have  access  to  Major  Subordinate  Commands  (MSCs)  through  the  satellite 
connectivity  at  the  battalion  level.  While  this  research  looked  at  transformational 
communication  technologies  for  the  UOC  and  CAC2S,  these  type  of  scenarios  are  mostly 
stationary  with  the  need  to  connect  a  relatively  large  node.  For  the  CoNDOR  scenario, 
the  situation  is  much  more  unique  as  units  could  be  stationary  one  minute  and  on-the- 
move  the  next.  In  the  traditional  structure  of  a  battalion,  the  company  headquarters  may 
be  stationary  long  enough  to  incorporate  what  is  recommended  for  the  UOC  and  CAC2S 
program.  Thus,  the  LOS  recommendations  for  the  communications  into  the  POP-V 
resemble  the  LOS  rankings  used  for  UOC  and  CAC2S.  Since  EPLRS  is  currently  the 
best  form  of  data  connectivity  down  to  the  lower  levels  at  56  Kbps,  it  is  obvious  that  the 
technologies  recommended  would  bring  a  new  kind  of  capability  down  to  the  lowest 
level.  The  following  technologies  are  recommended  for  LOS  into  the  POP-V  in  the  order 
of  preference:  FSO,  Microwave,  OFDM,  802.16,  and  802.1  lb  over  SecNet-1 1. 

The  first  recommendation  for  LOS  communications  is  to  use  FSO,  which 
has  a  throughput  capability  ranging  from  T1  (1.5  Mbps)  up  to  Gigabit  speeds  (1000 
Mbps).  The  setup  is  scalable  to  the  size  of  the  unit,  and  the  time  to  establish  connectivity 
with  the  POP-V  could  be  within  minutes.  The  microwave  product  examined  can  also 
vary  the  data  rate  from  T1  (1.5  Mbps)  but  only  up  to  OC-3  speeds  (155  Mbps).  This 
setup  is  more  cumbersome  to  the  user  and  frequency  licensing  is  an  issue  during 
peacetime.  Next,  OFDM  is  a  relatively  quick  and  simple  setup.  The  throughput 
capabilities  are  much  more  limited  compared  to  the  other  technologies  (up  to  72  Mbps), 
but  OFDM  is  much  more  effective  in  BLOS  situations  when  compared  to  the  other 
technologies.  802.16  could  be  a  nice  fit  communicating  into  the  POP-V  as  it  can  provide 
connectivity  in  a  360-degree  range,  but  it  is  limited  to  less  throughput  than  OFDM  at 
roughly  66  Mbps.  Finally,  802.11b  over  SecNet-11  is  much  more  flexible  in  the 
changing  environment  from  stationary  to  mobile,  and  it  has  Type  1  encryption  built  in. 
The  equipment  also  creates  a  small  footprint,  but  the  throughput  is  limited  to  1-5  Mbps 
depending  on  the  strength  of  the  signal. 

For  BLOS  situations  when  communicating  from  the  lower  echelons  to  the 

POP-V,  the  following  technologies  are  recommended  in  order  of  preference:  OFDM, 

Broadband  Satellite,  INMARSAT,  and  Iridium.  OFDM  can  become  the  technology  of 
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the  future  for  the  Marine  Corps  if  it  can  be  properly  encrypted  in  a  cost  effective  manner. 
The  ability  to  communicate  over  hills,  through  trees,  and  around  buildings  can  allow  the 
subordinate  units  communicating  with  the  POP-V  to  maintain  an  effective  security 
posture  while  still  achieving  high  throughput  capabilities  up  to  24  Mbps.  Broadband 
satellite  connectivity  can  be  packaged  in  a  suitcase  size  unit,  but  the  cost  of  using  the 
services  at  such  low  echelons  may  be  unrealistic.  INMARSAT  and  Iridium  provide  no 
greater  increase  in  throughput  over  the  current  LOS  radios,  but  they  do  offer  the 
flexibility  to  talk  BLOS/OTH. 

b.  Out  of  POP-V  to  MSC 

When  communicating  from  the  POP-V  to  an  MSC,  the  scenario  will  most 
likely  require  some  form  of  BLOS  or  OTH  connectivity.  The  distance  is  unpredictable 
enough  that  some  form  of  satellite  connectivity  is  needed  at  this  site  to  attain  the  required 
communications  to  the  MSC.  INMARSAT  or  some  form  of  TACSAT  can  provide  that 
connectivity,  but  the  Marine  Corps  is  looking  for  commercial  products  that  can  augment 
this  need.  During  the  various  field  tests,  the  authors  were  fortunate  enough  to  be  exposed 
to  several  leading  technologies  that  can  be  applicable  for  the  POP-V  to  MSC 
requirement.  In  a  BLOS  situation,  the  following  technologies  are  recommended  in  the 
order  of  the  authors  preference:  OFDM,  Broadband  satellite,  INMARSAT,  and  Iridium. 
OFDM  can  provide  a  terrestrial  connection  up  to  20  kilometers  and  can  reach  over  hills, 
through  trees,  and  around  buildings.  This  technology  can  also  be  retransmitted  if  the 
situation  dictates.  The  next  three  technologies.  Broadband  satellite,  INMARSAT,  and 
Iridium,  were  also  ranked  in  the  same  order  for  OTH  capability. 

Segovia/Omega  Systems  Broadband  satellite  connectivity  during  Field 
Test  Four  was  most  impressive.  They  are  able  to  vary  the  amount  of  throughput  that  is 
needed  and  can  provide  private  network  capabilities,  Internet  services,  and  phone 
services.  Their  link  can  also  be  Type  1  encrypted,  which  could  provide  SIPRNET 
connectivity.  INMARSAT  can  be  employed  while  stationary,  but  the  cost  is  just  not 
comparable  to  what  other  service  providers  can  offer  when  stationary.  Iridium  has  a  low 
throughput  of  up  to  9.6  Kbps  when  combining  four  Iridium  channels.  It  is  recommended 
last  because  of  the  throughput.  However,  the  technology  is  currently  available,  as 
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evidenced  by  its  use  at  the  Marine  Corps  Warfighting  Lab  for  the  Expeditionary  Tactical 
Communications  System. 

c.  Communications  on-the-Move 

(1)  Within  the  Convoy.  Communications  on-the-move  is  what  the 
CoNDOR  architecture  is  built  for.  Since  current  LOS  radios  can  communicate  on-the- 
move,  transformational  communications  needs  to  be  able  to  replicate  this  functionality. 
In  order  to  improve  throughput  within  a  convoy  of  vehicles,  which  in  the  CoNDOR 
scenario  may  be  a  company  or  platoon  convoy,  several  technologies  were  evaluated  for 
applicability  at  this  level.  The  recommendations  resemble  those  that  were  made  for  UOC 
and  CAC2S  since  the  technologies  can  be  used  at  any  level.  The  following  are  the 
recommendations  in  order  of  priority:  OFDM,  802.11b  over  SecNet-11,  and  Iridium. 
OFDM  will  again  provide  sufficient  bandwidth  for  a  platoon/company  sized  unit,  enable 
a  small  footprint,  and  allow  vehicles  flexibility  on  where  to  locate  in  a  convoy.  802.1  lb 
over  SecNet-1 1  offers  similar  benefits  but  LOS  must  be  maintained  between  the  vehicles. 
This  is  the  main  reason  it  is  ranked  second  behind  OFDM,  despite  the  encryption 
capabilities  of  SecNet-11.  Innovative  methods  can  be  explored  to  encrypt  the  OFDM 
link  in  a  cost  effective  manner.  Finally,  Iridium  is  recommended  as  the  third  option  for 
this  scenario  due  to  its  capability  to  be  used  on-the-move,  and  it  could  provide  a  small 
sized  unit  in  a  convoy  with  a  sufficient  amount  of  bandwidth. 

(2)  Outside  the  Convoy.  This  category  is  most  applicable  to  how 
units  will  maintain  connectivity  with  the  POP-V  while  on-the-move.  If  there  is  a 
company  or  platoon  size  unit  that  is  traveling  in  a  convoy,  then  they  need  to  have  some 
means  of  maintaining  connectivity  to  the  POP-V  in  order  to  be  connected  with  all  other 
units  associated  with  that  POP-V.  Again,  this  mirrors  the  communications  on-the-move 
section  for  UOC  and  CAC2S.  INMARSAT  is  the  first  recommendation  due  to  the  on¬ 
board  satellite  terminal’s  ability  to  track  the  aerial  satellite  while  in  motion.  This  is 
currently  a  costly  solution,  but  Marine  Corps  Systems  Command  is  exploring  options  to 
have  users  share  the  bandwidth,  which  in  turn  would  reduce  the  cost.  The  second 
recommendation  is  to  use  Iridium  due  to  its  being  available  now  and  the  ability  to  use  it 
an  unlimited  amount.  In  addition,  it  can  be  used  on-the-move  and  from  anywhere  on  the 
battlefield  to  talk  back  to  the  POP-V.  The  down  side  is  that  the  throughput  offers  no 
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more  than  the  current  existing  LOS  radios.  Lastly,  OFDM  is  recommended  for 
communications  with  the  POP-V  while  on-the-move  because  of  its  capability  to  maintain 
connectivity  over  adverse  terrain  conditions.  On  the  other  hand,  the  distance  OFDM  can 
traverse  is  roughly  20  kilometers  without  a  retransmission  site.  This  is  the  reason  for 
ranking  it  last  when  compared  to  INMARSAT  and  Iridium. 

(3)  For  Short/Long  Halts.  As  units  maneuver  throughout  the 
battlefield  in  convoys,  there  will  be  times  when  the  convoy  will  make  a  short  or  long 
halts  that  produce  opportunities  to  establish  connectivity  while  stationary.  This  then 
turns  into  the  BLOS  scenario  that  was  explained  earlier  for  communications  into  the 
POP-V.  If  within  distance  of  a  POP-V,  then  the  number  one  choice  remains  OFDM  due 
to  its  inexpensive  cost  and  unique  capabilities.  The  second,  third,  and  fourth 
recommendation  all  depend  on  satellite  communications.  These  are  all  going  to  be  more 
costly,  although  Broadband  satellite  could  be  packaged  for  smaller  units.  It  can  also 
provide  a  sufficient  amount  of  bandwidth  for  a  small  unit  at  a  justifiable  cost. 
INMARSAT  connectivity  could  possibly  allow  multiple  users  to  share  the  64  Kbps 
currently  offered.  If  upgrades  are  accomplished  as  expected,  then  there  will  be  more 
bandwidth  to  share.  Iridium  will  offer  a  means  to  communicate  that  is  already  paid  for, 
but  the  throughput  offers  no  more  than  the  LOS  radios.  However,  Iridium  does  offer 
BLOS/OTH  voice  and  data  connectivity. 

d.  Aerial  Relay 

The  use  of  aerial  relays  for  CoNDOR  can  greatly  increase  the  ability  to 
communicate  from  units  to  the  POP-V  and  from  the  POP-V  to  MSCs.  This  could  be  an 
alternative  to  relying  on  LOS  radios  or  satellite  communications.  The  two  technologies 
examined  in  this  thesis  are  recommended  for  use  in  the  aerial  relay  platform,  802.11b 
over  SecNet-1 1  and  OFDM.  802.1  lb  over  SecNet-1 1  can  be  retransmitted  via  the  aerial 
platform  for  hundreds  of  miles  if  the  signal  is  amplified  and  appropriate  antennas  are 
utilized.  If  it  is  determined  that  OFDM  can  be  amplified,  then  distance  can  equal  that  of 
802.1  lb  and  greater  flexibility  is  attained  at  the  locations  where  antennas  would  need  to 
be  placed  on  the  ground  to  maintain  connectivity  with  the  aerial  platform.  Since  802.1  lb 
was  tested  and  has  proven  to  work  at  various  distances,  this  technology  is  the  first 
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recommendation.  More  research  needs  to  be  conducted  with  OFDM  to  determine  the 
validity  of  using  it  as  a  technology  in  an  aerial  relay  platform. 

Several  commercial  off-the-shelf  technologies  were  examined  to 
determine  if  they  could  be  implemented  into  the  UOC,  CAC2S,  and  CoNDOR  programs 
within  the  next  few  years.  Based  on  this  research,  the  authors  developed  their 
recommendations  for  each  program.  The  research  team  decided  to  combine  the  UOC  and 
CAC2S  recommendations  since  the  command  and  control  systems  have  similar  distance 
requirements  when  physically  deployed  on  the  battlefield  and  the  requirements  for 
communications  on-the-move  are  very  much  alike.  CoNDOR  was  kept  separate  since  it 
is  not  a  command  and  control  system,  but  rather  a  concept  of  connecting  multiple 
echelons  of  command  together.  Table  44  below  was  developed  by  the  authors  to  assist 
them  in  making  the  recommendations  for  each  of  the  programs.  It  lists  the  pros  and  cons 
of  the  technologies  that  were  examined,  and  recommends  how  each  technology  should  be 
employed  in  the  communications  scenario  (LOS/BLOS/OTH).  Table  44  below  was  the 
driving  factor  that  assisted  the  authors  in  deciding  on  the  recommendations  displayed  in 
Table  43  above. 


FSO 

LOS 

Fiber  throughput  speeds,  quick  setup  time, 
operates  in  license  free  spectrum 

Susceptible  to  weather  conditions, 
short  distance  (<  5  km),  laser  alignment 

MICROWAVE  (RFM) 

LOS 

Up  to  OC-3  speeds,  already  packaged, 
reaches  out  to  13  kilometers 

Obtain  authorization  for  frequency  use, 
susceptible  to  interception  due  to  RF  use 

802.16 

LOS 

Adaptive  modulation,  up  to  66  Mbps, 

360  degree  coverage  out  to  20  km 

No  built-in  encryption,  company  evaluated  was 
ATM  based  (there  are  others  IP  based) 

802.11b  over  SecNet-11 

LOS 

Type  1  encryption  built-in, 
send  up  to  secret  level  data,  small  footprint 

Low  throughput  of  1-2  Mbps,  difficult  to  configure, 
not  compatible  with  other  802.1 1  b 

OFDM 

BLOS 

Communicates  over  hills,  through  trees,  and 
around  buildings,  25  Mbps  throughput 

Limited  encryption  built  in, 
need  good  azimuth  for  BLOS  connectivity 

BROADBAND  SATELLITE 
(Segovia/Omega  Systems) 

BLOS/OTH 

Large  throughput  capabilities  of  up  to  9  Mbps, 
mountable  on  a  vehicle.  Type  1  encryption 

Annual/Monthly  Fees,  but  not  by  minute 

INMARSAT 

(Nera) 

BLOS/OTH 

Satellite  connectivity  on-the-move, 
small  mountable  vehicle  platform,  encryption 

Expensive  per  minute  fees, 
low  throughput  of  56  Kbps  (working  on  upgrades) 

IRIDIUM 

BLOS/OTH 

Capable  of  combining  four  channels, 
comms  on-the-move,  no  monthly  fees 

Low  throughput  of  2.4  Kbps  per  channel, 
difficult  to  send  data  without  compression 

Table  44.  PRO/CONS  OF  EACH  EXAMINED  TECHNOLOGY 
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B.  WHAT  CAN  BE  IMPLEMENTED  IN  THE  FUTURE 

The  future  holds  many  possibilities  regarding  what  could  be  implemented  on  the 
tactical  battlefield.  In  order  to  meet  DoD’s  commitment  to  Joint  Vision  (JV)  2020,  laser 
communication  will  most  likely  be  the  leading  technology  because  of  its  high  throughput 
capability.  JV  2020  outlines  full-spectrum  dominance  and  network  centric  warfare,  but 
without  lasers  that  vision  is  only  a  dream.  In  addition,  technologies  such  as 
Transformational  Satellites,  Wideband  Networking  Waveform,  Joint  Tactical  Radio 
System;  and  concepts  such  as  Bandwidth  Sharing,  Quality  of  Service,  and  a  Joint 
Integrated  Common  Operating  Picture  are  critical  in  a  network  centric  environment. 
Many  efforts  are  being  employed  in  order  to  fully  develop  the  Transformational 
Communications  Architecture  (TCA).  In  the  following  sections  three  recommendations 
will  be  described  for  the  UOC/CAC2S/CoNDOR  scenarios,  a  wireless  recommendation 
will  be  described  in  a  FORCEnet  scenario,  and  follow-on  research  recommendations  will 
be  discussed. 

1.  UOC/CAC2S/CoNDOR 

a.  UA  V Laser  Communication 

Utilizing  aerial  relay  for  communications  has  proven  to  extend 
connectivity  on  the  tactical  battlefield.  The  idea  of  dedicating  a  UAV  for  this  service  is 
something  decision-makers  will  have  to  address  in  the  near  future.  Similar  to  how  aerial 
relays  currently  operate,  it  is  proposed  for  a  futuristic  transformational  communications 
network  that  UAV  laser  communications  be  utilized  in  order  to  enhance  the  maximum 
throughput  on  the  tactical  battlefield. 

The  concept  consists  of  a  UAV  with  laser  equipment  working  as  a  relay 
into  the  satellite  TCA  that  will  exist  in  2015  and  beyond.  Inside  the  UAV,  there  will  be 
several  lasers  that  will  have  the  ability  to  track  moving  objects.  The  laser  that  is  oriented 
to  the  sky  would  be  responsible  for  tracking,  sending,  and  receiving  information  from  the 
satellite  unit.  The  laser  that  is  oriented  laterally  would  be  responsible  for  tracking, 
sending,  and  receiving  information  from  other  aerial  units.  The  laser  that  is  oriented  to 
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the  ground  would  be  responsible  for  tracking,  sending,  and  receiving  information  from 
the  ground  unit.  Utilizing  the  UAV  this  way  allows  it  to  become  an  integral  part  of  the 
TCA. 

UAV  laser  communications  is  a  definite  option  for  future 
UOC/CAC2S/CoNDOR  communications.  The  suggested  application,  described  above, 
for  the  UAV  employing  laser  connectivity  among  the  units  on  the  tactical  battlefield  can 
potentially  be  achieved  within  the  next  two  decades.  A  diagram  illustrating  power  to  the 
tactical  edge  using  laser  connectivity  is  shown  below  (Figure  76). 
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Figure  77.  TCA  CIRCA  20 1 5  FROM  TCA  BREIF67 


The  reality  of  this  type  of  technology  and  concept  is  currently  being 
studied.  General  Atomics  Aeronautical  Systems,  Inc.  were  funded  in  2002-2003  for  an 
engineering  task  for  the  Jet  Propulsions  Laboratory  Lasercom  Terminal  and  UAV  Laser 
Communications  Project.  In  addition,  according  to  Free-Space  Laser  Communications 
Technologies,  a  demonstration  was  conducted  from  the  UAV-to-Ground  Lasercomm.68 

67  ADM  FISHER  BRIEF,  (SEPT  2003) 

68  Berardo  G.  Ortiz,  Shinhak  Lee,  Steve  Monacos,  Malcolm  Wright,  and  Abhijit  Biswas,  Jet 
Propulsion  Laboratory,  Califomina  Institute  of  Technology,  Pasadena  CA,  “Design  and  development  of  a 
robust  ATP  subsystem  for  the  Altair  UAV-to-Gound  Lasercomm  2.5  Gbps  Demonstration”  (SPIE,  2003) 
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This  reinforces  the  idea  of  being  able  to  use  laser  communications  and  UAVs  together. 
Lawrence  Livermore  National  Laboratory  in  Livermore,  CA,  is  conducting  additional 
work  in  an  attempt  to  solve  the  ground  to  air  tracking  problem. 

b.  Long  Range,  Ground-Based  Laser  Connectivity 
According  to  Jet  Propulsion  Laboratories,  “a  state  of  the  art  optical 
communications  telescope  laboratory  to  perform  research  and  development  of  laser  beam 
propagation  and  signal  detection  technologies  to  meet  NASA’s  future  needs  for  high- 
bandwidth  communications... ”69  is  being  examined.  This  illustrates  the  seriousness  of 
the  capability  of  laser  communications.  Another  futuristic  transformational 
communications  concept  is  the  ability  to  rely  on  the  unique  properties  of  femtosecond 
optical  pulse  in  order  to  increase  the  current  LOS  capabilities.  The  authors  recommend 
further  studies  into  the  femtosecond  optical  pulse  capability. 

Attochron,  LLC;  a  company  based  in  Los  Angeles,  CA,  specializes  in  free 
space  optical  communications  technologies.  According  to  Attochron,  “Femtosecond 
optical  pulses  can  provide  a  communications  bandwidth  1,000  times  greater  than  the 
current  microwave  line-of-site  technology.”70  Tom  Chaffee,  Founder  and  CTO  of 
Attochron,  LCC;  elaborates  on  Attochron’ s  capability,  “Attochron’ s  free  space  optical 
(FSO)  communications  and  power  delivery  technology  utilizes  the  physics  of  the  leader 
phase  of  lightning,  air  ionization,  which  allows  Nature  to  transmit  tremendous  amounts  of 
light  and  power  through  Earth’s  normally  insulative  atmosphere.  It’s  interesting  to  note 
that  this  is  possible  often  while  in  the  presence  of  inclement  weather  (fog,  clouds,  and 
rain).  Attochron  uses  two  ultra  fast  lasers  fired  in  sequence  to  achieve  ionization  of  air. 
The  first  laser  affects  an  ionized  aerial  waveguide  unaffected  by  the  diffraction  of  the 
atmosphere.  A  second  laser,  fired  immediately  afterwards,  maintains  the  stability  of  the 
ionized  pathway  and  provides,  with  its  beam,  the  medium  for  either  communications  or 
power  delivery. ”71  The  distance  this  technology  can  deliver  is  in  the  range  of  28  km. 
Studies  are  currently  being  conducted  to  increase  the  distance  and  capabilities  of  this  new 

69  K.E.  Wilson,  W.T.  Roberts,  V.  Garkanian,  F.  Battle,  R.  Leblanc,  H.  Hemmati,  and  P.  Robles,  “Plan 
for  Safe  Laser  Beam  Propagation  from  the  Optical  Communications  Telescope  Laboratory”  (February  15, 
2003). 

70  http://www.attochron.com/  (May  2004) 

71  Tom  Chaffee,  “Femtosecond  Laser  Air-Ioniztion  for  Free  Space  Optical  (FSO)  Communications 
and  FSO  Power  Delivery”  (Technical  White  Paper,  Attochron,  LLC  2002) 
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technology.  This  technology  when  proven  sound  could  be  an  excellent  fit  for  the 
UOC/CAC2S/CoNDOR  sites  for  BLOS  scenarios. 

c.  OFDM  in  Aerial  Relay 

A  technology  that  is  closer  to  being  usable  is  OFDM  in  an  Aerial  relay. 
This  concept  is  being  studied  at  the  Naval  Postgraduate  School  (NFS)  as  follow-on 
research  from  this  thesis.  In  a  series  of  experiments  called  Surveillance  Target 
Acquisition  Network  (STAN),  NPS  students  are  taking  commercial-off-the-shelf  OFDM 
products  to  extend  the  BLOS  capabilities  in  a  tactical  environment.  The  method  by 
which  this  is  accomplished  is  by  placing  the  OFDM  technology  in  a  tethered  balloon  or 
by  placing  the  technology  in  an  aerial  relay. 

In  the  next  STAN  experiment,  OFDM  will  be  placed  in  an  aerial  relay  in 
order  to  increase  BLOS  capabilities.  OFDM’s  unique  wave  characteristics  yield 
capabilities  for  this  technology  to  communicate  BLOS.  The  scenario  will  consist  of  a 
100-mile  distance  being  covered  by  an  OFDM  signal.  However,  there  are  concerns  that 
OFDM  may  not  be  able  to  be  amplified  from  the  aerial  relay.  Regardless,  one  site  will  be 
located  at  NPS  (Monterey,  CA),  while  the  other  site  will  be  in  Camp  Roberts,  CA.  The 
aerial  relay  will  retransmit  the  OFDM  signal  between  sites.  The  expected  throughput 
values  are  in  the  neighborhood  of  10  to  20  Mbps.  The  capability  of  passing  sensor, 
voice,  and  computer  data  will  be  tested  on  the  IP-based  OFDM  backbone.  This 
demonstration  is  an  example  of  how  UOC/CAC2S/CoNDOR  can  take  advantage  of 
commercial-off-the-shelf  technology  and  implement  it  in  a  tactical  environment  in  order 
to  communicate  in  a  BLOS  scenario. 

2.  FORCEnet  Application 

A  wireless  recommendation  in  a  FORCEnet  scenario  consists  of  integrating  a  call 
for  fire  scenario  on  the  tactical  battlefield  with  wireless  technologies.  In  a  study 
conducted  by  Space  and  Naval  Warfare  Systems  Command  (SPA WAR),  Charleston,  SC; 
they  addressed  this  recommended  wireless  solution  for  the  FORCEnet  scenario. 

Efforts  spear-headed  by  Dennis  L.  Gette,  code  6 IB  Transformational  Science  and 
Technology;  have  demonstrated  a  prototype  FORCEnet  Engagement  Package  (FNEP) 
Combat  Reach  Capability  (CRC).  The  FNEP  is  a  small-scale  system  that  integrates  joint 

sensors,  platforms,  weapons,  networks,  and  Command  and  Control  (C2)  systems.  The 
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CRC  is  achieved  through  distributed  services  available  in  the  FORCEnet  cloud  via  the 
FNEP.  An  extract  of  the  demonstration  is  provided  as  a  recommendation  for  an 
integrated  transformational  network-centric  environment  for  a  futuristic 
UOC/CAC2S/CoNDOR. 

SPAWAR-Charleston  demonstrated  a  scaled-down  prototype  version  of  a 
FORCEnet-enabled  CRC.  The  prototype  is  based  on  a  Call  for  Fire  (CFF)  As-Is 
Operational  View  (OV).  Aecording  to  Mr.  Gette,  “The  As-Is  OA  for  a  USMC  CFF  is 
presented  as  an  Operational  View  (OV-1)  in  Figure  77.  The  OV-1  serves  to  illustrate  the 
sequence  of  tasks  or  operational  activities  that  take  plaee  as  dictated  by  eurrent  Taeties, 
Teehniques,  and  Proeedures  (TTPs).”72  Figure  77  depiets  the  current  call  for  fire 
scenario. 


72  Dennis  L.  Gette,  Space  and  Naval  Warfare  Systems,  Transformational  Science  and  Technology; 
“Demonstrate  a  Prototype  FORCEnet  Engagement  Package  (FNEP)  Combat  Reach  Capability  (CRC)”  (Jan 
2004) 
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Figure  78.  AS-IS  CALL  FOR  FIRE  OPERATIONAL  VIEW  (OV-I) 

The  current  process  requires  Forward  Observers  (FOs)  and  Forward  Air 
Controllers  (FACs)  to  place  the  call  for  fire.  The  FO  converts  the  information  to  an 
AFATDS  input  and  passes  the  input  to  the  Company  (Co)  level.  The  CO  decides  if  the 
call  for  fire  is  valid  and  then  passes  the  information  to  the  Bn.  The  Battalion  Fire  Support 
Coordinator  (Bn  FSC)  passes  the  input  to  the  Bn  CO,  who  decides  if  the  call  for  fire  is 
valid.  The  Bn  CO  then  tasks  the  Bn  FSC  to  validate  the  request,  selects  the  weapon 
system,  and  passes  the  request  to  the  selected  unit. 

A  couple  of  points  to  take  away  from  the  OV-1  are:  (1)  The  task  of  converting 
information  to  AFATDS  input  is  sometimes  difficult,  suggesting  that  a  sensor  should 
automatically  convert  the  input  into  useable  data.  (2)  The  OV-1  relies  on  single  channel 
radios  to  communicate  with  Co  HQ  and  Bn  FSC  Center.  This  connectivity  maximizes  at 
16  kbps,  which  is  low  throughput  on  the  tactical  battlefield.  (3)  The  final  point  is  the  FOs 
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and  FACs  do  not  have  access  to  a  common  operational  picture.  Current  TTPs  do  not 
prescribe  the  need  for  a  common  operational  picture  at  that  level  and  many  will  argue 
within  the  operational  community  that  the  FOs  and  FACs  do  not  have  the  time  to  look  at 
or  use  the  common  operational  picture. 

According  to  Mr.  Gette,  “Under  the  (unofficial)  STOM  CONOPS  portrayed  in 
Figure  78,  platoons  can  call  for  fire  directly.  In  this  To-Be  OV,  a  different  Operational 
Facility  (OPFAC)  other  than  the  Bn  FSC  can  validate  the  CFF,  select  the  appropriate 
weapons  system(s),  convert  the  request  to  AFATDS  format,  and  pass  the  request  to  the 
selected  unit.  Notice  that  the  Co  only  intervenes  if  the  call  for  fire  is  inappropriate  (e.g., 
based  on  a  target’s  value  or  priority). ”73  The  figure  below  provides  an  environment  for 
the  junior  leaders  to  make  decisions  based  on  the  Commander’s  intent.  This  environment 
favors  centralized  command  and  decentralized  control  meaning  the  junior  leader  is 
capable  of  carrying  out  the  Commander’s  intent  with  minimal  supervision.  A  network¬ 
centric  environment  should  provide  higher  commands  with  the  capability  to  pass 
information  down  to  the  lower  echelons  and  promote  more  efficient,  synchronized 
operations  without  impacting  centralized  command  and  decentralized  control. 
Implementing  this  approach  would  require  significant  changes  to  existing  Tactics, 
Techniques,  and  Procedures. 


73  Dennis  L.  Gette,  Space  and  Naval  Warfare  Systems,  Transformational  Science  and  Technology; 
“Demonstrate  a  Prototype  FORCEnet  Engagement  Package  (FNEP)  Combat  Reach  Capability  (CRC)”  (Jan 
2004) 
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Figure  79.  TO-BE  CALL  FOR  FIRE  OPERATIONAL  VIEW  (O V- 1 ) 


According  to  Mr.  Gette,  “The  Fast  Ethernet  Tactical  Network  is  based  on  an  on¬ 
going  effort  by  SPAWAR-Charleston  and  the  USMC  to  test  and  evaluate  new  approaches 
for  improving  the  mobility  and  performance  of  tactical  networks  that  will  support  the 
multi-function/multi-mission  node-to-node  operations  of  the  CAC2S.”74  The  Fast 
Ethernet  Tactical  Network  was  used  for  the  prototype  experiment.  The  prototype 
experiment  reinforced  the  efforts  of  the  current  authors  because  the  prototype 
demonstrated  Free  Space  Optics  (wireless  technology)  as  potential  solutions  for  intra- 
nodal  and  inter-nodal  connectivity  for  UOC  or  CAC2S. 


74  Dennis  L.  Gette,  Space  and  Naval  Warfare  Systems,  Transformational  Science  and  Technology; 
“Demonstrate  a  Prototype  FORCEnet  Engagement  Package  (FNEP)  Combat  Reach  Capability  (CRC)”  (Jan 
2004) 
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According  to  Mr.  Gette,  “For  the  limited  demonstration  shown  in  Figure  79,  an 
FSO  link  will  be  used  to  distribute  a  Common  Tactical  Picture  (CTP)  from  a  Command 
and  Control  (C2)  Producing  Node  to  an  FO,  Co,  or  Bn  FSCC  Consumer  Node  on  the 
FORCEnet  Tactical  Internet.  By  subscribing  to  an  up-to-date  CTP,  it  may  be  possible  for 
partieipating  units  in  an  Amphibious  Assault  Operation  to  eoordinate  and  eonduct  a  Joint 
Fire  Operation  on  multiple  fixed,  moving,  and  aerial  targets.”75 
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Figure  80.  FAST  ETHERNET  TACTICAL  NETWORK 


The  Fast  Ethernet  Tactical  Network  above  demonstrated  the  potential  eapability 
of  a  call  for  fire  seenario.  The  important  faetor  to  extraet  is  that  the  throughput  on  the 


75  Dennis  L.  Gette,  Space  and  Naval  Warfare  Systems,  Transformational  Science  and  Technology; 
“Demonstrate  a  Prototype  FORCEnet  Engagement  Package  (FNEP)  Combat  Reach  Capability  (CRC)”  (Jan 
2004) 
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tactical  battlefield  is  eurrently  limited  and  stove-piped.  Through  eontinuous  efforts  by 
the  FORCEnet  studies  group  and  agencies  like  SPAWAR-Charleston  a  network-eentrie 
environment  will  be  available  for  the  taetical  warrior. 

Dennis  Gette  sums  it  up  best  by  saying,  “The  bottom  line  is  that  bottlenecks  and 
chokepoints  between  the  Ground  and  Aviation  Combat  Elements  of  the  MAGTF  are 
common  occurrences  because  of  high  network  loading  and  low  throughput.  To  further 
exaeerbate  this  problem  are  the  interoperability  ehallenges  that  are  ereated  by  the  added 
complexity  of  the  structure  and  employment  eonsiderations  of  other  Service  equipment, 
ageneies,  doetrine,  and  personnel  in  joint  operations.”'76 

3.  Follow-on  Research 

The  next  several  paragraphs  diseuss  possible  follow-on  researeh  for  other  thesis 
students  to  address.  These  are  areas  the  authors  believe  may  assist  the  UOC,  CAC2S, 
and  CoNDOR  programs  even  further  as  this  thesis  work  is  completed. 

First,  throughout  the  testing  evolutions  of  this  research  the  authors  implemented 
commercial  off-the-shelf  technologies  into  the  established  networks  formulated  by  the 
authors.  The  data  colleeted  was  mostly  throughput  data  of  fde  transfers,  voice  calls,  and 
streaming  video.  This  did  not  replicate  actual  data  produced  by  a  UOC,  CAC2S,  or 
CoNDOR  scenario.  During  May  2002,  CAC2S  used  an  Optimized  Network  Engineering 
Tool  (OPNET)  to  model  the  actual  network  traffic  that  would  be  generated  during  live 
operations.  This  model  was  using  the  MRC-142  and  TRC-170  throughput  capabilities 
between  nodes  and  fiber  runs  in  the  intra-nodal  setup.  Further  research  could  be  done 
with  OPNET  to  model  and  simulate  the  new  wireless  teehnologies  reeommended  for  eaeh 
of  the  three  programs.  This  would  provide  further  examination  of  the  benefits  of  these 
transformational  wireless  teehnologies  for  the  Marine  Corps. 

This  research  project  dealt  mostly  with  point-to-point  communieations. 
Therefore,  a  single  point  of  failure  within  the  network  arehitecture  would  eause 
degradation  aeross  the  entire  network.  For  example,  in  Field  Test  Four  if  conneetivity 
through  the  tethered  balloon  was  lost,  the  NOC  would  not  have  been  able  to 

76  Dennis  L.  Gette,  Space  and  Naval  Warfare  Systems,  Transformational  Science  and  Technology; 
“Demonstrate  a  Prototype  FORCEnet  Engagement  Package  (FNEP)  Combat  Reach  Capability  (CRC)”  (Jan 
2004) 
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communicate  with  MRC  #1  and  MRC  #2.  If  the  NOC  was  employing  some  type  of 
point-to-multipoint  technology  that  connected  to  the  POP  and  MRC  #2,  then  redundant 
communications  would  have  been  established.  Follow  on  research  could  focus  on  the 
point-to-multipoint  technologies  that  this  research  was  unable  to  address. 

The  above  statements  also  yield  to  a  good  lead  into  another  research  area,  which 
is  mesh  architecture.  In  mesh  architecture,  the  communication  devices  in  the  network 
recognize  each  other.  This  leads  to  a  self-healing,  self-forming  network  when  in  each 
communication  device  can  sense  the  other  communication  devices  in  its  environment  and 
is  able  to  communicate  within  its  surroundings.  Once  the  communication  device 
identifies  its  surroundings,  then  it  can  relay  information  via  the  mesh  architecture  to  its 
neighboring  devices.  This  type  of  technology  is  a  truly  network-centric  environment  that 
is  required  for  the  future. 

Next,  Broadband  satellite  was  employed  during  Field  Test  Four.  It  provided 
stationary  communications  services,  but  the  satellite  dish  mounted  on  the  SUV  was  able 
to  pull  into  a  site  and  automatically  track  where  the  satellite  antenna  was  located.  If  this 
type  of  service  can  be  provided  while  on-the-move,  units  can  keep  an  updated  common 
operational  picture  even  when  displacing.  Omega  Systems,  maker  of  the  satellite  dishes 
at  Field  Test  Four,  said  they  are  working  on  these  satellite  capabilities  for  on-the-move 
communications.  Follow  on  research  could  study  the  impact  of  using  high  throughput 
(Broadband  satellite)  capability  while  in  motion  and  how  it  can  effectively  be 
implemented  into  the  UOC,  CAC2S,  and  CoNDOR. 

Several  technologies  that  provide  transformational  throughput  were  evaluated  in 
this  research.  Most  had  no  encryption  built  into  them,  the  exception  being  Redline  and 
Alvarion  with  their  OFDM  products.  Further  research  is  also  warranted  to  identify  if  the 
technologies  tested  could  have  Type  1  encryption  built  into  them.  Since  Type  1 
encryption  is  currently  in  stand-alone  devices,  the  researched  being  suggested  is  to  imbed 
the  encryption  into  the  product.  Since  Harris  did  this  with  their  SecNet-1 1  cards,  the  idea 
should  be  feasible,  providing  the  proper  agencies  were  involved.  If  so,  this  would 
alleviate  having  to  insert  two  bulk  encryption  devices  into  either  side  of  a  link  to  encrypt 
and  decrypt  information. 
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Furthermore,  the  next  topie  of  eonducting  a  cost  analysis  of  replacing  legacy 
communications  systems  with  the  commercial  off-the-shelf  technologies  could  also  be 
researched.  While  the  cost  of  the  product  can  be  taken  into  consideration,  the  cost  of 
encryption  may  be  the  biggest  expense.  A  formula  could  be  developed  to  determine  what 
is  more  important  to  the  Marine  Corps  —  cost  or  capability. 

The  technology  that  proved  most  impressive  during  the  last  two  field  tests  was 
OFDM.  To  incorporate  a  technology  in  the  Marine  Corps  architecture  that  can 
communicate  over  hills,  through  trees,  and  around  building  may  save  lives  by  eliminating 
the  need  for  retransmission  sites.  This  research  did  not  evaluate  OFDM  while  traversing 
over  large  mountains.  A  breaking  point  of  where  the  technology  is  still  useful  would  be 
another  good  follow  on  research  topic.  In  addition,  the  use  of  OFDM  was  not  evaluated 
over  water.  Since  the  technology  breaks  up  a  single  carrier  into  multiple  carriers,  more 
detailed  research  could  identify  if  water  has  any  adverse  effects  on  the  usefulness  of  this 
technology.  Finally,  OFDM  is  unproven  in  aerial  relays.  The  need  to  research  whether 
the  signal  can  be  amplified  in  an  aerial  scenario  would  be  beneficial.  This  would  identify 
if  the  technology  were  better  suited  to  employ  aerial  than  802.1  lb. 

There  is  only  one  NS  A  certified  Type  1  encryption  device  known  that  can  encrypt 
classified  traffic  in  a  wireless  LAN.  This  device  is  the  Harris  SecNet-11  card.  Much 
research  has  been  done  with  the  product,  but  more  extensive  research  needs  to  be  done  to 
identify  how  a  SecNet-11  access  point  handles  multiple  users  in  a  wireless  LAN  at  the 
same  time.  This  follow  on  research  would  identify  how  much  traffic  load  an  access  point 
could  handle,  and  how  these  access  points  need  to  be  employed  at  different  levels  of 
command. 
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APPENDIX 


A.  FSONA 

fSONA  Communications  is  a  provider  of  current  and  next  generation  FSO 
solutions.  Their  corporate  headquarters  is  in  Richmond,  British  Columbia,  Canada. 
Founded  in  1997  with  a  goal  to  develop  optical  transmission  products  for  the  broadband 
access  market,  fSONA  created  the  SONAbeam™  family.  The  SONAbeam  comes  in 
three  different  series,  M,  S,  and  E.  The  M  series  has  four  transmitting  lasers,  the  S 
series  and  E  series  have  two.  Each  series  offers  different  throughput  capabilities  that 
vary  from  1.5  Mbps  to  1.25  Gbps. 77  fSONA  has  also  recently  completed  the 
development  of  an  OC-48  prototype  system,  the  SONAbeam  1250-M.  The  SONAbeam 
155-M  and  SONAbeam  155-E  were  used  during  this  thesis  research. 

Throughout  the  testing  evolutions,  we  noticed  many  advantages  of  the 
SONAbeam  155-M.  The  SONAbeam  155-M  puts  out  640  milliwatts  of  power,  which 
is  the  most  of  any  company’s  product  we  worked  with,  and  its  four  transmitting  lasers 
help  offset  effects  of  scintillation.  The  SONAbeam  155-M  advertises  the  longest 
distance  at  5700  meters  out  of  any  FSO  product,  which  was  within  the  scope  of  our 
testing.  The  skin  of  the  SONAbeam  155-M  is  made  of  cast  aluminum,  which  is  very 
durable  material.  Cast  aluminum  is  designed  to  withstand  rugged  environments  such  as 
those  encountered  in  the  military.  Finally,  the  lasers  use  the  1550  nanometer 
wavelength,  which  is  suitable  for  the  military  due  to  laser  designators  being  in  the  700- 
850  nanometer  range. 

A  couple  of  disadvantages  to  the  SONAbeam  155-M  were  that  it  requires  a  very 
stable  platform  to  be  mounted  on.  Both  heavy  duty  (200  pounds)  and  lightweight 
mounts  (50  pounds)  were  used  during  the  testing  events.  The  SONAbeam  155-M  is 
also  a  very  heavy  piece  of  equipment  weighing  nearly  44  pounds. 


77  http://www.fsona.com  (April  2004). 
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The  SONAbeam  155-M  is  made  for  an  environment  that  is  statie  such  as  that 
found  at  an  Air  Command  Node  (ACN)  within  the  CAC2S  architecture.  It  could  also 
be  used  at  MAGTF  level  headquarters  to  connect  the  COC  with  the  communications 
site. 

On  the  other  hand,  the  SONAbeam  155-E  is  a  very  lightweight  piece  of 
equipment,  which  can  be  mounted  on  top  of  a  telescopic  stand.  This  allows  the 
SONAbeam  155-E  to  be  used  with  units  that  displace  often. 

For  information  on  fSONA  and  their  products,  contact  Mike  Corcoran  at  877-463- 
7662  (office)  or  604-312-6176  (cell).  His  e-mail  address  is  mcorcoran@fsona.com. 


B.  LIGHTPOINTE 

Founded  in  1998  by  Heinz  Willebrand,  Ph.D.,  a  research  visionary  in  the  field  of 
physics  and  lasers.  LightPointe's  application-specific  Flight™  Optical  Wireless  family 
combines  the  speed  of  fiber  with  the  flexibility  of  wireless.  Their  products  transmit  voice, 
data,  and  video  at  bandwidths  ranging  from  single  T-l/E-1  up  to  2.5  Gbps  at  distances  up 
to  4  km,  over  any  protocol.  Over  2,000  of  their  products  are  installed  in  over  60 
countries.  Two  of  Lightpointe’s  partners  include  Cisco  and  Corning  Cable  Systems. 78 

The  Flight  product  line  includes  the  FlightLite,  FlightSpectrum,  and  FlightStrata. 
During  this  research,  the  FlightStrata  was  used  at  connectivity  speeds  of  1.25  Gbps  and 
155  Mbps. 

The  unique  aspect  about  the  equipment  used  was  the  Fly  Away  kit  that  the  link 
head  and  accessory  equipment  were  packaged  in.  This  consisted  of  a  case  that  was  about 
5x2x2  feet.  A  complete  link  would  consist  of  having  two  cases,  each  weighing  about  70 
pounds.  The  link  was  the  easiest  to  establish  out  of  all  companies  involved  in  this 
research  project.  From  start  to  finish,  a  link  was  established  within  15  minutes  with  two 
inexperienced  personnel  setting  up  the  equipment.  The  stand  was  very  lightweight  that 
the  link  head  was  placed  on. 


78  http://www.lightpointe.com/index.cftn/fuseaction/corporate.aboutus  (April  2004). 
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Alignment  of  the  lasers  is  fairly  straightforward;  the  seope  that  is  used  to  initially 
align  the  lasers  is  mounted  within  the  link  head  and  then  LED  bars  light  up  on  the  baek  of 
the  link  head  to  signify  the  strength  of  the  signal.  Lightpointe  ehose  to  utilize  the  750- 
850  nanometer  range  for  their  lasers,  but  they  have  stated  that  they  could  operate  in  the 
1550  nanometer  range  if  the  demand  was  established. 

Lightpointe’s  Fly  Away  kit  is  ready  for  deployment  right  now,  and  it  is  definitely 
packaged  the  best  out  of  all  FSO  companies.  However,  the  skin  of  the  link  head  would 
have  to  be  ruggedized  to  withstand  harsh  environments.  Their  products  could  be  used  at 
any  level  in  the  UOC  or  CAC2S  architectures.  It  also  could  be  an  option  in  the 
CONDOR  setup  at  the  company  level  talking  to  the  POP  vehicle. 

For  information  on  Lightpointe  and  their  products,  contact  Jim  McGowan  at  858- 
643-5216  (office)  or  858-232-4873  (cell).  His  e-mail  address  is 
imcgowan@lightpointe.com. 

C.  MRV 

Founded  in  1988,  MRV  Communications,  Inc.  is  a  public  company.  With  1,500 
employees,  MRV  maintains  eight  R&D  and  manufacturing  centers  in  the  U.S.,  Europe, 
Israel,  and  the  Far  East  and  50  customer  service,  support  and  sales  offices  in  22  countries. 
MRV  FSO  products  sold  to  the  Federal  markets  are  U.S.A.  manufactured.  MRV  is  the 
Worldwide  leader  of  FSO  with  more  than  6,000  FSO  links  and  have  19  FSO  patents. 
MRV  has  over  20  years  of  R&D  in  FSO  technology,  and  they  were  originally  funded  by 
DARPA  to  further  develop  the  FSO  technology.  Their  R&D  included  a  2,000  kilometer 
FSO  link  to  a  satellite  supporting  tracking.  MRV  has  DoD  installations  of  their  FSO 
products  including  the  Army  and  Air  Force.  Furthermore,  MRV  has  four  different 
product  lines  that  they  manufacture:  Advanced  Terminal  Servers  secure  IT  solutions  for 
remote  control/access,  media  converters,  Terescope  Optical  Wireless  (FSO),  and  Optical 
switches,  routers,  and  modems. 79  The  Terescope  3000  was  used  during  the  testing 
evolutions,  along  with  the  FSO-RF  automatic  switch,  OptiSwitch. 


79  http://www.tnrv.com/corporate  (April  2004) 
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Many  advantages  are  found  with  MRV  and  their  products.  First,  the  company  has 
been  around  for  a  long  time  and  they  have  a  diversity  of  products,  so  they  do  not  rely 
solely  on  FSO  for  revenue.  For  these  reasons,  they  are  a  company  to  depend  on  for  the 
long  term.  The  Terescope  3000  was  set  on  a  lightweight  telescopic  stand  and  it  was 
relatively  easy  to  setup.  It  had  a  camera  alignment  tool  so  one  could  see  the  laser  light 
from  the  opposite  end  on  the  viewing  screen.  This  allowed  for  the  link  head  to  be  easily 
maneuvered  into  the  cross-hairs  on  the  screen  for  alignment.  The  OptiSwitch  was  quite 
impressive.  When  FSO  and  RF  links  are  attached  using  the  MRV  patent  Terescope 
Fusion,  the  Terescope  Fusion  automatically  goes  to  the  strongest  link.  Thus,  if  fog  rolls 
in  and  the  FSO  link  loses  signal  to  the  other  side,  then  the  RF  takes  over.  This  is  all 
transparent  to  the  user  as  there  was  no  time  delay  or  break  in  transferring  files.  For 
MRV’s  media  converters,  the  latest  technology  allows  one  to  pick  and  choose  what 
“pluggable”  optical  transceivers  and/or  electrical  interfaces  they  want  to  use.  These 
Small  Form  Factor  Pluggables  (SFPs)  are  also  going  to  be  engineered  into  future  MRV 
FSO  products  which  will  allow  the  end  user  to  always  have  the  right  interface  to  connect 
to  the  network  equipment.  The  customer  will  not  have  to  consider  which  scope  head  to 
purchase  for  single-mode  or  multi-mode  fiber  or  worry  about  media  converters.  This  will 
be  built  into  the  head  of  the  scope. 

MRV’s  Terescope  products  and  accessories  are  suitable  for  any  level  of  command 
in  the  UOC,  CAC2S,  and  CONDOR  communications  architectures. 

For  information  on  MRV  Communications  and  their  products,  contact  Tim 
Kcehowski  at  724-934-5991  (office)  or  412-596-1729  (cell).  His  e-mail  address  is 
tkcehowski@mrv.com. 


D.  TERABEAM 

Terabeam  was  founded  in  1997  and  its  headquarters  is  in  Redmond,  WA.  They 
produce  FSO  products  along  with  60  GHz  millimeter  wave  (MMW)  systems. 80  The 
Elliptica,  FSO  product,  was  used  during  our  testing  events,  and  the  MMW  system  was 
demonstrated. 

80  http://www.terabeam.cotn/home.shtml  (April  2004). 


220 


Terabeam  uses  only  one  laser  eompared  to  other  eompanies  that  use  multiple 
lasers.  To  paraphrase  Carrie  Cornish  on  February  4,  2004  at  Raytheon  in  San  Diego,  CA, 
“...Terabeam  uses  a  higher  quality  single  laser,  because  over  distance  multiple  lasers  end 
up  overlapping  which  provides  no  more  of  a  benefit  than  the  single  laser...”  The  one 
laser  does  use  the  1550  nanometer  wavelength,  a  more  favorable  wavelength  for  use  in 
military  operations. 

The  features  that  make  Terabeam’s  Elliptica  stand  out  are  the  quality  of  their  lab 
procedures  in  developing  the  product,  significant  auto-tracking  feature  that  compensates 
for  movement,  ease  of  setup  and  teardown,  minimal  amount  of  small  parts  to  lose  over 
time,  and  the  camera  feature  to  align  the  links. 

After  visiting  Terabeam’s  lab  one  could  see  the  impressive  procedures  set  in  place 
to  ensure  the  product  is  fully  developed  and  tested  before  going  to  the  customer.  The 
auto-tracking  feature  is  also  unique.  It  can  compensate  for  movement  of  buildings, 
accidental  movement  of  the  stand,  and  for  the  stand  settling  into  the  ground.  Products 
that  can  be  set  up  and  tom  down  in  an  expedient  manner  are  looked  at  favorably  in  the 
military  environment.  It  is  also  important  to  develop  systems  with  a  minimal  amount  of 
small  parts.  Over  time,  small  parts  will  definitely  get  lost  in  the  military  environment. 
The  Elliptica  was  simple  to  set  up,  easy  to  use,  and  free  of  clutter  and  small  parts.  The 
camera  feature  for  the  alignment  assists  in  establishing  a  link  very  quickly.  After 
hooking  up  a  laptop  to  the  Elliptica,  all  the  user  has  to  do  is  look  at  the  picture  that  the 
camera  from  the  linkhead  is  providing  and  move  the  link  head  appropriately  to  line  up 
with  the  other  side. 

As  the  Elliptica  is  a  very  suitable  alternative  to  the  UOC,  CAC2S,  and  CONDOR 
communications  architectures,  the  skin  of  the  Elliptica  would  have  to  be  hardened  for  the 
constant  wear  and  tear  it  would  undergo  in  the  field. 

For  information  on  Terabeam  and  their  products,  contact  Jim  Olson  at  610-408- 
9380  (office)  or  206-604-7429  (cell).  His  e-mail  address  is  iim.olson@terabeam.com. 
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E.  ENSEMBLE 


Ensemble  was  founded  in  1997  and  its  headquarters  is  in  San  Diego,  CA.  Their 
wireless  broadband  system  (Fiberless)  includes  radio  transmission  base  stations  and 
antennas,  multiplexers,  and  network  management  software  capable  of  providing  both 
Internet  connections  and  voice  services.  Ensemble  Communications  designs, 
manufactures,  and  markets  point-to-multipoint  wireless  system  for  Local  Multipoint 
Distribution  Services  (LMDS).8i  They  also  offer  network  design,  product  integration, 
and  project  management  services. §2  The  16200  Hub  Station,  the  320  Multiplexer,  and 
the  Fiberless  282  Series  Outdoor  Mounted  Unit  (ODU)  were  used  for  the  experiments. 

Alignment  of  the  antennas  was  straightforward;  the  authors  pointed  the  antennas 
in  the  direction  of  each  other.  Once  there  was  connectivity  between  the  two  antennas,  the 
320  Multiplexer  and  the  16200  Hub  Station  would  illuminate  a  connectivity  light  on  each 
component  respectively.  The  unique  quality  of  their  wireless  broadband  system  was  the 
three  major  components  took  little  effort  to  set  up.  From  start  to  finish,  antenna 
alignment  was  established  within  1 5  minutes  with  two  inexperienced  personnel  setting  up 
the  equipment.  In  addition  to  the  ease  of  antenna  set  up.  Ensemble  Communications  took 
advantage  of  the  available  bandwidth  by  carrying  the  largest  packet  payload  of  any  point- 
to-multipoint  system.  83  The  largest  packet  payload  is  accomplished  by  Ensemble 
Communications’  Adaptix  technology.  Ensemble  Communications’  Adaptix  technology 
consisted  of  combining  Adaptive  Time  Division  Duplexing,  Adaptive  Time  Division 
Multiple  Access,  and  Adaptive  Modulation.  This  patent  maximizes  the  spectrum  by 
taking  advantage  of  the  entire  waveform. 

One  disadvantage  that  Ensemble  Communications  faced  during  testing  events  was 
that  equipment  was  an  ATM  based  system.  The  configuration  for  the  routers  was 
extremely  difficult  and  extremely  time  consuming.  In  one  particular  case,  the  router  and 
network  configuration  took  up  to  eight  hours  before  any  testing  was  able  to  take  place. 

Ensemble  Communications  was  closed  in  April  2004. 

81  http://www.ensemble.com  (May  2004) 

82  http://www.hoovers.com/ensemble-communications/— ID  104236— /free-co-factsheet. xhtml  (May 
2004) 

83  http://www.ensemble.com  (May  2004) 
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F.  ALVARION 

Founded  in  1992,  Alvarion  was  solely  focused  on  broadband.  Alvarion  is  a  world 
provider  for  Point-to-Multipoint  (PMP)  Broadband  Wireless  Access  (BWA).  Alvarion 
supplies  integrated  solutions  to  telecom  carriers  in  order  to  assist  telecom  carriers  in 
providing  sustainable  voice  and  data  connectivity  in  the  broadband  market.  The 
broadband  market  covers  residential  area,  SOHO  (small  office,  home  office),  markets 
through  small  and  medium  enterprises,  and  multi-tenant  units/  multi-dwelling  units. 
Alvarion  introduced  its  BreezeACCESS  VL  system.  The  BreezeACCESS  VL  system  is 
a  PMP  wireless  broadband  system  which  operates  between  the  5.725  to  5.850  Ghz 
frequency  band.  This  system  uses  OFDM  technology  in  order  to  maximize  performance 
when  the  distant  end  is  not  line  of  sight.  Some  equipment  characteristics  include:  an 
OFDM  system,  Adaptive  modulation  (BPSK,  QPSK,  16  QAM,  64  QAM),  a  channel 
bandwidth  of  20  Mhz,  enhanced  security,  automatic  transmit  power  control,  and  offers 
over-the-air  software  upgrade  and  configuration  upload/download.84 

The  BreezeACCESS  VL  demonstrated  a  quick  and  easy  set  up.  The  outdoor  unit, 
which  consists  of  antennas  and  a  radio,  was  erected  on  a  lightweight  retractable  pole, 
which  was  secured  by  parking  a  vehicle  over  the  base  plate  of  the  pole.  Once  the  outdoor 
unit  was  secured  and  aligned,  the  indoor  unit  was  connected  to  the  network’s  router. 

The  issue  that  Alvarion  encountered  was  the  alignment  of  the  antennas.  On  the 
underside  of  the  antenna,  there  is  a  module  that  indicates  signal  strength  level,  which  is 
not  visible  when  adjusting  the  antenna.  This  small  dilemma  could  be  resolved  through 
the  use  of  either  moving  the  module  to  where  it  can  be  seen  when  adjusting  the  antenna 
or  by  replacing  the  module  with  some  sort  of  audio  indicator  that  notifies  the  technician 
the  antenna  is  aligning  properly. 

For  information  on  Alvarion  and  their  products,  contact  Jasper  Bruinzeel  at  760- 
517-3149  (office)  or  760-685-2015  (cell).  His  email  address  is 
i  asper  .bruinzeel@alvarion.  com. 


84  http://www.alvarion-usa.cotn/RunTime/Materials/PDFFiles/alv  BA%20VL  pg.pdf  (May  2004) 


223 


G.  REDLINE 


Founded  in  1999,  Redline  Communications  Inc.  is  headquartered  in  Markham, 
Ontario,  Canada.  Redline  Communications  is  an  innovative  provider  of  second- 
generation  broadband  fixed  wireless  systems. 85  Redline’s  products  are  based  on  an 
advanced  form  of  OFDM  technology.  This  technology  interlocks  three  different 
techniques  which  include  the  OFDM  data  engine;  an  increased  efficiency  of  the  medium 
access  control  layer  and  the  radio  frequency;  and  multipath  distortion  effects  and 
interference. 

Redline  Communications  introduced  the  AN-50  OFDM  system  with  sector  and 
omni-directional  antennas.  The  AN-50  system  operates  in  the  license-exempt  5.8  GHz 
band  and  includes  advanced  technologies  to  address  potential  inter-cell  interference 
issues.  The  AN-50  maximizes  spectral  efficiency  with  a  unique  patented  bi-directional 
adaptive  modulation  technique,  automatically  selecting  any  of  eight  modulation  schemes 
providing  a  solid  connection  even  in  challenging  link  conditions.  In  addition,  the  AN-50 
delivers  an  over-the-air  rate  of  up  to  72  Mbps,  a  robust  non-line-of-sight  (NLOS) 
capability,  and  audible  antenna  alignment  and  diagnostic  capabilities. 86 

Redline  Communications  equipment  was  very  easy  to  set  up.  The  alignment  of 
the  antenna  was  augmented  by  an  audio  signal  that  assisted  the  technician  in  the 
alignment.  This  feature  proved  to  be  extremely  helpful  in  the  set  up  /  tear  down  process 
of  the  system.  The  OFDM  technology  demonstrated  to  be  a  BLOS  technology  up  to  20 
km  (depending  on  the  antenna  used). 

The  only  issue  that  Redline  encountered  during  the  testing  evolution  was  that  their 
switch  could  only  be  set  to  auto  negotiate.  In  order  to  maximize  throughput  across  the 
link,  the  test  bed  was  designed  around  the  network  routers  to  be  configured  at  speed  100 
Mbps  with  full  duplex.  The  miss-matched  configuration  degraded  the  link  across  the 
network  and  limited  the  maximum  throughput  the  equipment  was  capable  of  producing. 


85  http://www.redlinecotnmunications.com  (May  2004) 

86  Redline  Communications,  “Redline  Family  White  Paper”,  October  2003. 
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For  more  information  on  Redline  Communications  and  their  product,  contact 
Dave  Rumore  at  (905)  479-8344  (office)  or  (561)  254-0758  (cell).  His  email  is 
drumore@redlinecommunications.com. 

H.  SEGOVIA  (BROADBAND  SATELLITE) 

Segovia  was  founded  in  2002  and  is  headquartered  in  Herndon,  Virginia.  Segovia 
provides  omnipresent  Global  IP  networks  and  services.  The  IP  coverage  that  is  provided 
by  Segovia  covers  virtually  a  unified  global  network.  During  the  testing  evolution, 
Segovia  was  teamed  up  with  Omega  Systems,  a  company  who  produces  the  satellite 
dishes.  Segovia’s  throughput  can  range  from  128  kbps  to  9  Mbps.  Segovia’s  Internet 
service  features  no  limit  on  monthly  usage,  high  performance  with  low  cost,  Type-1 
encryption  compliant,  and  a  fully  managed  solution.  Segovia’s  IP  Voice  features  high 
quality  voice,  full  range  of  PBX  features,  and  reduced  costs.  In  addition,  Segovia  offers  a 
VPN  feature,  which  includes  easy  IP  administration,  security,  use  of  the  Internet,  and 
completely  private  network.87 

Segovia’s  customer  service  and  teamwork  left  a  customer  oriented  impression  on 
these  authors.  Senior  Sales  Engineer,  Ross  Warren,  went  above  and  beyond  expectations 
in  order  to  assist  in  making  Field  Test  Four  a  success.  His  coordination  with  his 
headquarters  arranging  for  the  airborne  satellite  to  act  as  a  retransmission  site  for  the  link 
between  the  two  testing  sites  was  key.  In  addition  to  providing  customer  support  for  his 
equipment,  he  also  assisted  the  students  with  the  configuration  of  the  entire  network  of 
routers,  switches,  access  points,  and  IP  phones. 

For  more  information  on  Segovia  or  Segovia’s  services,  contact  Jeff  Howard  at 
(703)621-6450.  His  email  is  ieff.howard@segoviaIP.com. 

I.  OMEGA  SYSTEMS,  INC. 

Omega  Systems,  Inc.  was  founded  in  1998  and  is  headquartered  in  Colorado 
Springs,  Colorado.  Omega  Systems  was  the  company  that  provided  the  satellite  antennas 
for  Field  Test  Four.  Omega  Systems  is  not  only  a  satellite  antenna  company.  They  also 

87  http://www.segoviaip.com/  (May  2004) 
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develop  requirements-based  solutions  derived  from  a  thorough  analysis  of  the  customer’s 
internal  process  and  external  communications  needs. 88  Omega  Systems  provides  the 
following  products  and  services:  Business  Process  Analysis  and  Re-engineering, 
Requirements  Analysis,  Network  Engineering,  Application  Engineering,  System  Analysis 
and  Integration,  C4ISR  Architecture  Analysis,  Internet  Business  Solutions,  and  IT 
Equipment  Sales  and  Services. 89 

Marine  Corps  specific  projects  that  Omega  Systems  Inc.  has  supported  with  onsite 
support  are:  C2  Operational  Architecture  for  Marine  Corps  Combat  Development 
Command  (MCCDC);  Network  Design,  Installation,  and  Management  for  Marine  Corps 
Institute;  Warfighting  Functional  Analysis  for  MCCDC;  USMC  Online  Correspondence 
Course  System  for  Marine  Corps  Institute;  LHA-R  Operational  Architecture  for  MCCDC 
and  SPAWAR,  and  Single  Integrated  Operational  Picture  for  MCCDC.90 

Omega  Systems,  Inc  introduced  two  one-meter  satellite  terminals  during  the  field 
testing  evolution.  One  terminal  was  a  ground  terminal  that  was  utilized  at  the  Mobile 
Research  Facility;  the  other  was  mounted  on  a  Sports  Utility  Vehicle  and  was  located  at 
the  remote  site.  The  ground  terminal  was  a  multiple  case  system  that  was  powered  by  a 
llOV  source,  and  its  transmitting  frequency  was  between  13.75  -  14.50  GHz  with  a 
receiving  frequency  between  11.70  -  12.75  GHz.  The  satellite  dish  was  manually 
pointed  at  the  satellite  for  connectivity.  The  mounted  terminal  required  the  same  power 
load  and  it  operated  in  the  same  frequency  band.  However,  it  automatically  aligned  itself 
to  the  satellite  once  it  was  turned  on.  This  yields  for  a  quick  setup  time  and  operation  of 
the  equipment  can  begin  within  minutes. 

For  more  information  on  Omega  Systems,  Inc.  contact  Matt  Jones  at  (719)  886- 
2212  (office)  or  (719)  337-1588  (cell).  His  email  address  is  mjones@omegasvs.net. 


88  http://www.omegasvs.net/documents/corporatecs.pdf  (May  2004) 

89  www.omegasvs.net  (May  2004) 

90  Matt  Jones,  VP  Business  Development,  “Past  Performance  Addendum,  Omega  Systems  Inc.”  (May 
2004) 
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J.  NERA  (INMARSAT) 

Nera  ASA,  based  in  Norway,  was  established  in  1947,  and  it  is  one  of  the  world's 
leading  companies  in  the  field  of  wireless  telecommunications  using  microwave  and 
satellite  technology.  The  company  has  offices  in  26  countries  and  more  than  1,500 
employees  around  the  world.  Separate  companies  for  product  development  and  sales  are 
located  in  Boston,  MA  and  Dallas,  TX.91  Nera’s  NWC  Voyager  system,  INMARSAT 
capabilities  on-the-move,  was  looked  at  closely  during  the  March  testing  event.  Marine 
Corps  Systems  Command  is  also  looking  at  Nera  for  possible  mobile  communications  for 
the  CONDOR  architecture.  Finally,  the  World  Communicator  was  also  demonstrated  but 
not  used  during  the  course  of  research  in  these  testing  evolutions. 

NWC  Voyager  is  a  vehicular  Global  Area  Network  (GAN)  satellite  terminal 
operating  over  INMARSAT  1-3  in  spot-beam,  prepared  for  1-4.  The  GAN  capability 
combines  the  high  quality  and  speed  of  the  full  mobile  ISDN  64  kbps  service  with  the 
flexibility  of  Mobile  Packet  Data  Services  (MPDS).92 

As  discrete  and  convenient  as  hand  luggage,  the  Nera  WorldCommunicator 
enables  one  to  access  the  internet  and  send  and  receive  e-mail,  data  files,  fax  and  voice 
messages  from  one  compact  unit  anywhere  in  the  world.  By  linking  two  units  together 
the  throughput  is  doubled  to  128  kbps. 93 

During  the  testing,  the  NWC  Voyager  was  easily  mounted  on  a  solid  platform 
made  of  wood  in  the  back  of  a  pickup  truck.  While  the  vehicle  was  in  motion,  phone 
calls  and  file  downloads  were  performed  without  error.  There  were  some  issues, 
however,  when  the  look  angle  of  the  Voyager  was  blocked  by  hills  next  to  the  vehicle  the 
download  was  unsuccessful.  In  addition,  integrating  the  Voyager  system  into  the 
established  network  was  not  accomplished  during  the  testing  event. 

Nera’s  products  are  definite  players  in  the  military,  mobile  communications 
realm.  Communicating  on  the  move  has  emerged  as  a  requirement  to  keep  commanders 
informed  at  all  times. 

91  http://www.nera.no/index.html  (April  2004). 

92  http://www.nera.no/5243067FA7B57D0BC1256E510054623A.html  (April  2004). 

93  http://www.nera.no/844AED60C2F14035C1256A300054A93D.html  (April  2004). 
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For  information  on  Nera  and  their  products,  contact  Peter  Coffman  at  713-294- 
4543  (cell).  His  e-mail  address  is  pc@nera-sp.com. 

K.  IMUX  (IRIDIUM) 

General  Dynamics’  Reachback  Iridium  Inverse  Multiplexer  (IMUX)  combined 
four  2.4  Kbps  Iridium  channels  to  increase  the  overall  bandwidth  to  9.6  Kbps. 94  The 
IMUX  utilized  the  channels  by  separating  the  input  information  and  sending  the  parsed 
information  across  the  four  different  channels.  Another  Reachback  unit  recombines  the 
original  information  by  using  buffers  in  order  to  compensate  for  variations  in  link  delays 
produced  from  the  four  satellite  channels. 95  The  four  L-band  channels  were  wired  into 
the  IMUX  box  that  provided  three  modes  of  operation;  data,  video,  and  voice 
transmission.  The  data  mode  ensured  data  was  not  altered  during  transmission  (data  fdes, 
critical  imagery,  etc.).  The  video  transmission  mode  did  real-time  video  transmission 
using  custom  video  compression  software  (used  when  loss  of  video  quality  can  be 
tolerated).  The  voice  mode  was  a  satellite  telephone. 

The  Reachback  can  be  implemented  in  a  variety  of  combinations  to  include 
mobile-to-mobile,  mobile-to-network,  and  mobile-to-Public  Switched  Telephone 
Network  (PSTN).  The  mobile-to-mobile  configuration  allows  two  Reachback  units  to 
communicate  with  each  other.  The  mobile-to-network  allows  a  mobile  Reachback  unit  to 
communicate  back  to  a  central  server.  The  mobile-to-PSTN  configuration  allows  a 
mobile  Reachback  unit  to  communicate  to  four  standard  PSTN  phone  lines. 

During  the  testing,  the  product  performed  as  expected.  The  IMUX  is  definitely  a 
current  solution  option  for  BLOS.  Although  the  throughput  is  limited,  the  product  does 
offer  configurations  that  augment  more  data  throughput  on  the  tactical  battlefield. 

For  more  information  on  the  IMUX,  contact  Don  Lesmeister  at  (480)  441-0340 
(office)  or  (480)  518-2208  (cell).  His  email  address  is  Donald.Lesmeister@gdds.com. 


94  http://www.gdds.com/satelliteservices/  (May  2004) 

95  www.gdds.com.  white  paper,  “Reachbak  Iridium  Inverse  Mulitplexer  for  Over-the-Horizon 
Worldwide  Transmission  of  Voice,  Video,  and  Data”  (May  2004) 
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L.  GENERAL  DYNAMICS  (REM) 

The  Radio  Frequency  Module  is  a  product  produced  by  Ceragon  Networks; 
however,  the  product  is  packaged  by  General  Dynamics  Decision  Systems  (GDDS). 
GDDS  packages  the  product  in  appropriate  cases  along  with  a  Cisco  2950  switch  for  their 
customers.  This  case  along  with  the  microwave  dish  is  field  expedient  and  hardened  to 
withstand  a  rugged  military  environment.  The  antenna  sits  on  top  of  a  lightweight 
telescopic  stand,  which  is  separate  from  the  case.  A  distance  of  9  kilometers  can  be 
reached  with  the  one- foot  antenna,  which  was  used  during  the  testing  event,  and  13.5 
kilometers  with  the  two-foot  antenna.96  RFM  is  a  point-to-point,  line-of-sight,  OC-3 
capable  (155  Mbps)  microwave  product. 

According  to  a  General  Dynamics  data  sheet,  “RFM  v3  contains  a  baseband 
assembly  with  power  supply,  an  Ethernet  switch,  and  a  dual  DSl  to  fiber  optic  modem 
that  is  operated  and  maintained  inside  the  transit  case  located  inside  user  provided 
facilities.  It  also  contains  an  RF  assembly  and  antenna  that  are  installed  and  operated 
outside  the  user  provided  facilities  up  to  200  feet  away.”97  This  self-contained  system 
demonstrated  a  consolidated  system  that  provided  high  80 ’s  Mbps  throughput  of  data. 

During  the  testing,  the  product  was  very  impressive.  The  RFM  could  be 
implemented  now  in  the  Marine  Corps  for  intra-nodal  and  inter-nodal  connectivity. 

For  more  information  on  the  RFM,  contact  Jon  Seime  at  (480)  441-2983  (office) 
or  (480)  510-4126  (cell).  His  email  address  is  ion.seime@gdds.com. 


M.  KG-235 INE 

GDDS  is  the  manufacturer  of  the  KG-235  Sectera  In-Line  Network  Encryptor 
(INE).  The  KG-235  is  specifically  designed  to  support  IP/Ethemet  operating  over 
standard  commercial  networks  that  require  U.S.  Government  Type  1  security,  but  it  is 
also  used  in  the  military  environment.  The  INE  protects  all  levels  of  data,  from 
Government  Classified  to  TS/SCI.  It  provides  confidentiality,  data  integrity,  peer 
identification,  authentication  and  mandatory/discretionary  access  control  services.  The 

96  GDDS,  “Radio  Frequency  Module  (RFM)  v3  Handout”,  2003. 

97  GDDS,  “Radio  Frequency  Module  (RFM)  v3  Data  Sheet”,  2003 
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INE  is  software  configurable,  it  utilizes  the  new  Sectera  INE  Configuration  Manager,  and 
it  is  keyed  using  material  supplied  by  the  U.S.  Government’s  Electronic  Key 
Management  System  (EKMS)  for  Type  1  products.98  The  interfaces  on  the  INE  are  two 
RJ-45  10/100  Base-T  and  two  DB-9  Serial  Ports.  The  INE  can  support  up  to  17  Mbps  of 
aggregate  data  throughput.99  With  further  upgrades,  the  INE  will  be  able  to  support  up  to 
60  Mbps.  100 

During  the  testing,  the  product  did  not  perform  as  expected.  The  INE  needed  the 
latest  firmware  in  order  to  maximize  a  greater  throughput  and  the  authors  were  expecting 
a  higher  throughput  result  from  the  product.  When  the  INE  was  tested  at  Raytheon,  the 
INE  had  an  older  version  of  firmware  installed.  The  INE  specifications  rate  the  product 
up  to  17  Mbps  aggregate  data  throughput. loi  The  maximum  throughput  observed  for  the 
nSfE  was  around  5  Mbps. 

For  more  information  on  the  INE,  contact  Don  Lesmeister  at  (480)  441-0340 
(office)  or  (480)  518-2208  (cell).  His  email  address  is  Donald.Lesmeister@gdds.com. 


N.  SECNET-11 

SecNet-11  is  a  Harris  product.  Harris  Corporation  is  an  international 
communications  equipment  company  focused  on  providing  product,  system,  and  service 
solutions  for  commercial  and  government  customers.  1 02  The  company  is  headquartered 
in  Palm  Bay,  Florida.  Providing  service  worldwide,  Harris  has  sales  and  service  facilities 
in  more  than  90  countries.  103 

SecNet-1 1  is  a  tool  for  a  secure  802. 1  lb  wireless  local  area  network.  The  SecNet- 
11  product  family  offers  a  scalable,  mobile,  quick  to  deploy  solution  for  a  military 
environment.  The  SecNet-11  family  includes  products  like  the  SecNet-11  Plus  PC  card, 

98  http://www.gdc4s.cotn/Products/sectera.htm  (April  2004). 

99http://www.gd-decisionsvstems.com/sectera/ine/upgrade/C4SSectera  INE  PIB  V2  12-5-03.pdf 

(May  2004) 

100  Donald  Lesmeister,  GDDS  sales  engineer,  phone  conversation  (February  2004) 

101  http://www.gdc4s.com/Products/secteraspecs.htm 

102  http://www.harris.com/  (May  2004) 

103  www.harris.com  (May  2004) 
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the  SecNet-11  PC  card,  the  SecNet-11  Wireless  Bridge,  the  SecNet-11  Access  Point,  and 
the  SecNet-1 1  Key  Fill  Cable.  Based  on  the  IEEE  802.1  lb  standards,  the  SecNet-1 1  Plus 
PC  card  has  been  certified  as  part  of  the  National  Security  Agency’s  (NSA)  Commercial 
COMSEC  Evaluation  Program  (CCEP).i04 

As  discussed  in  the  thesis,  SecNet-1 1  operated  as  expected.  SecNet-1 1  is  a  secure 
National  Security  Agency  (NSA)  Type  1  and  FIPS- 140  compliant  encryption  device. 
Therefore,  classified  information  up  to  Secret  can  be  passed  across  a  SecNet-1 1  network. 

For  more  information  on  SecNet-11  and  its  family  of  products,  contact  Mark 
Slepikas  at  (321)  727-5141  (office)  or  (321)  917-7019  (cell).  His  email  address  is 
mslepika@harris.com. 


O.  JTRS 

According  to  Harris,  “The  Joint  Tactical  Radio  System  (JTRS)  is  a  U.S.  military 
initiative  to  develop  a  family  of  software  programmable  and  modular  communications 
systems  that  will  become  the  principal  means  of  communications  for  warfighters  in  the 
digital  battlefield  environment.  All  waveforms,  protocols,  encryption,  and 
communications  processes  will  be  implemented  in  Software  Defined  Radio  (SDR) 
technology.  JTRS  is  a  family  of  affordable,  high  capacity,  software  programmable 
tactical  radios  providing  interoperability  for  line  of  sight,  and  beyond  line  of  sight  in  a 
wireless  mobile  network.  JTRS  is  identified  in  five  clusters;  cluster  1  will  consist  of 
ground  vehicular,  rotary  wing,  and  TACP;  cluster  2  will  consist  of  handheld  devices; 
cluster  3  will  consist  of  Maritime  and  fixed  sites;  cluster  4  will  consist  of  fixed-wing 
(Airborne);  and  cluster  5  will  consist  of  embedded  devices. ”105  According  to  LtCol 
Wilson,  “...through  the  addition  of  WNW,  the  JTRS  will  significantly  improve  tactical 
networking  on  the  battlefield.”  106 

Testing  was  not  conducted  due  to  the  infancy  of  the  system.  Therefore,  JTRS  is 
briefly  discussed  in  the  conclusions  of  this  thesis.  For  further  information  on  JTRS  and 

104  http://govcomm.harris/secure-comm/  (May  2004) 

105  http://www.rfcotnm.harris.com/itrs.html  (May  2004). 

106  Jefferey  D.  Wilson,  Lieutenant  Colonel,  United  States  Marine  Corps,  “Introducing  the  Joint 
Tactical  Radio”  (Marine  Corps  Gazette,  Aug  2002) 
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its  clusters,  contact  Captain  Andrew  G.  Chapman,  United  States  Marine  Corps,  at  (703) 
432-4360.  His  e-mail  address  is  ChapmanAG@mcsc.usmc.mil. 


P.  ATM 

As  mentioned  earlier.  Ensemble  operated  off  an  Asynchronous  Transfer  Mode 
(ATM)  network.  The  ATM  was  developed  because  there  was  a  need  for  delivering 
services  (video,  voice,  and  data)  at  high  rates  of  speed  across  a  network  of  computers. 
Networks  of  the  past  consisted  of  a  network  of  telephone  systems.  Integrated  Services 
Digital  Network  (ISDN).  The  technology  ATM  replaced  was  circuit  switched  Time 
Division  Multiplexing  (TDM).  The  nice  feature  ATM  offered  was  that  ATM  provided 
more  bandwidth  to  be  available  across  the  network  when  compared  to  TDM.  Most 
carriers  of  Internet  Protocol  (IP)  services  have  maintained  for  years  an  ATM  layer  over 
which  IP  traffic  travels.  This  was  due  to  the  reliable,  scalable,  higher  availability,  and 
Virtual  Private  Network  features  that  lie  within  ATM  and  lack  in  traditional  IP,  such  as 
the  lack  of  flow  control  and  sequencing.  IP  technology  today  does  not  lack  flow  control 
or  sequencing. 

The  manner  in  which  ATM  worked  with  data  has  changed  drastically  over  the 
past  decade.  ATM  in  the  past  had  a  major  shortfall  in  data  environments  due  to  “cell- 
tax”,  meaning  there  was  significant  overhead  in  packet-oriented  networks.  For  instance, 
if  a  piece  of  data  was  sub-divided  into  ATM’s  short  fixed  length  packets  of  53  bytes  and 
several  packets  were  full  except  one  which  only  had  a  few  bytes  in  it,  then  ATM’s 
overhead  would  fill  that  packet  and  send  it  across  the  network.  This  was  not  the  most 
practical  of  solutions,  so  adoption  of  the  Frame-based  ATM  over  Synchronous  Optical 
Network  (SONET)/Synchronous  Digital  Transport  took  place.  ATM  still  continued  to 
add  value  to  IP-based  services  through  means  like  SONET.  ATM  would  also 
simultaneously  offer  other  non-IP  applications  and  services  to  reside  on  the  same  core 
infrastructure.  However,  according  to  Comer,  “ATM  has  not  been  widely  accepted. 
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Although  some  phone  companies  still  use  it  in  their  backbone  networks,  the  expense, 
complexity  and  lack  of  interoperability  with  other  technologies  have  prevented  ATM 
from  becoming  more  prevalent.”! 07 

Q.  LINKSYS  (802.11 A/802.1  IB) 

Linksys  is  a  company  that  merged  with  Cisco.  The  authors  used  several  access 
points  made  by  Linksys.  In  particular  the  WAP55AG  was  used  in  access  point 
configuration.  The  WAP55AG  is  a  Linksys  Dual-Band  Wireless  A+G  Access  Point. 
The  product  contains  two  separate  radio  transceivers  in  order  to  support  three  wireless 
specifications.  The  first  transceiver,  2.4  GHz  frequency  band,  supports  the  802.11b 
standard  and  the  802. llg  standard.  The  second  transceiver,  5.4  GHz  frequency  band, 
supports  the  802.1  la  standard. 

The  product  was  fairly  difficult  to  configure  in  the  beginning.  Towards  the  end  of 
the  experiments  the  configuration  of  the  product  was  straightforward  because  of  the 
experience.  This  product  would  be  a  good  fit  within  an  unclassified  military  network. 

The  WAPl  1  was  another  Linksys  product  that  was  tested  by  these  authors.  The 
WAP  11  uses  802.11b  standard  for  its  technology.  The  WAP  11  was  used  in  a  bridge 
mode  configuration  to  tie  two  networks  together.  The  WAPl  1  was  also  used  in  an  aerial 
relay  configuration.  Initially,  the  WAPl  1  was  fairly  difficult  to  configure.  The  WAPl  1 
was  straightforward  to  configure  at  the  end  of  all  of  the  testing  evolutions.  Similar  to  the 
WAPS  SAG,  this  product  can  be  used  in  an  unclassified  environment  in  the  military. 

For  more  information  on  the  Linksys  or  the  Linksys  products,  contact  George 
Delisle  at  703-484-5733  (office)  or  703-217-7599  (cell).  His  e-mail  address  is 
gdelisle@cisco.com. 

R.  CISCO 

Cisco  was  founded  in  1984  by  a  small  group  of  computer  scientists  from  Stanford 
University.  It  now  has  over  34,000  employees  and  is  based  in  San  Jose,  CA.  Cisco  was 

107  Douglas  Comer,  “Computer  Networks  and  Internets  with  Internet  Applications”,  (Prentice-Hall 
Inc,  New  Jersey  2001,  third  edition),  pg.  229 
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founded  on  a  culture  based  on  the  principles  of  open  communication,  empowerment, 
trust,  integrity,  and  giving  back  to  the  communityios,  and  the  authors  witnessed  these 
same  values  in  their  dealings  with  Cisco.  In  December  2003,  the  authors  approached  a 
Cisco  Account  Manager  in  the  District  of  Columbia  area,  George  Delisle,  who  works 
closely  with  the  Marine  Corps.  A  request  was  granted  by  Mr.  Delisle  to  supply  the 
authors  with  two  Cisco  3745  Multiservice  Access  Routers,  two  Cisco  IP  Phone  7960Gs, 
one  CallManager  Server,  two  Cisco  350  Aironet  Bridges,  one  ATM  interface  card,  and 
four  Gigabit  Interface  Converters  (GBIC)  to  be  utilized  during  their  testing  exercises. 

Key  features  for  the  Cisco  3745  are  as  follows:  two  integrated  10/100  LAN  ports, 
two  integrated  Advanced  Integration  Modules  (AIM)  slots,  three  integrated  WAN 
Interface  Card  (WIC)  slots,  four  Network  Module  (NM)  slots,  two  High  Density  Service 
Module  (HDSM)  slots,  32MB  Compact  Flash,  128MB  DRAM,  and  support  for  all  major 
WAN  protocols  and  media.  109 

The  Cisco  IP  Phone  7960G  offers  four  dynamic  soft  keys  that  guide  a  user 
through  call  features  and  functions.  Built-in  headset  port  and  integrated  Ethernet  Switch 
are  standard  with  the  Cisco  IP  Phone  7960G.  It  also  includes  audio  controls  for  full 
duplex  speakerphone,  handset  and  headset.  The  Cisco  IP  Phone  7960G  also  features  a 
large,  pixel-based  LCD  display. no 

The  Cisco  Call  Manager  Server  that  was  used  was  the  MCS-7825H-2.2 
EVVl  model.  Next,  the  Cisco  350  Aironet  Bridges  were  not  used  during  the  testing 
events.  An  ATM  interface  card  provided  a  single-mode  intermediate-reach  (SMI)  fiber 
uplink  port  with  enhanced  performance.  This  was  used  with  Ensemble’s  equipment. 
Finally,  the  GBIC  accepted  a  multimode  fiber  at  a  wavelength  of  850  nanometers,  and  the 
port  took  a  SC-type  connector.  The  GBIC  was  successfully  used  with  Lightpointe’s  fiber 
cable  from  their  link  head. 


108  http://newsroom.cisco.com/dlls/companv  overview.html  (April  2004). 

109  http://www.cisco.coni/en/US/products/hw/routers/ps282/ps284/index.html  (April  2004). 

110 

http://www.cisco.coni/en/US/products/hw/phones/ps379/products  data  sheet09 1 86a008009 1 984.html 

(April  2004) 
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For  information  on  Cisco’s  support,  contact  George  Delisle  at  703-484-5733 
(office)  or  703-217-7599  (cell).  His  e-mail  address  is  gdelisle@cisco.com. 


S.  SPIRENT  (SMARTBITS) 

For  decades,  the  world’s  leading  communications  companies  have  used  Spirent 
solutions  to  conduct  performance  analysis  tests  in  labs  on  the  latest  technologies.  As  new 
communications  services  are  introduced  in  the  market,  Spirent  provides  the  tools  to  offer 
service  assurance  and  field  test  for  improving  troubleshooting  and  quality.  Spirent 
Communications  has  1,800  employees  in  14  countries,  and  its  headquarters  is  in 
Rockville,  MD.m 

During  the  Raytheon  testing,  Spirent  allowed  the  authors  to  utilize  their  Smartbits 
product  to  analyze  the  network  and  technologies  being  evaluated.  The  following  is  a  list 
of  the  Smartbits  products  that  were  utilized  during  testing:  SMB-600  Chassis,  LAN 
3101B  6-port  10/100  Ethernet  interface,  SWF-1208A  SmartVoIPQoS,  and  ACC-1040A 
Nanosync  GPS  Interface  Kit.  A  separate  company,  Zyfer,  provided  the  GPS  receivers 
and  antennas. 

The  GPS  receivers  and  antennas  were  used  to  synchronize  the  two  chassis  on 
separate  ends.  Unfortunately,  the  network  at  Raytheon  headquarters  was  positioned  too 
close  to  the  building,  so  the  look  angle  of  the  GPS  antenna  could  not  see  the  satellite. 
Thus,  the  two  chassis  could  not  provide  any  latency  data,  but  they  were  able  to  provide 
throughput  tests. 

Through  the  Smartbits  packet  generator,  each  technology  was  stressed  to  its 
fullest  allowing  one  to  see  the  exact  throughput  of  the  link.  This  was  mostly  done  with 
voice  and  data  traffic  in  a  full  duplex  setup.  At  times,  voice  and  data  were  done 
separately.  For  the  most  part,  eight  voice  calls  were  replicated  both  ways,  and  data  was 
sent  in  increments  of  10  Mb  starting  at  10  and  ending  at  100  Mb.  Overall,  this  setup 
allowed  one  to  see  what  amount  of  frame  loss  was  being  experienced  as  traffic  got 
heavier  and  heavier.  As  the  frame  loss  become  closer  to  100  percent,  a  determination 
could  be  made  on  the  exact  throughput  for  the  established  link. 

1 1 1  http://www.spirentcom.com/about/index.cfm?wt=l  (April  2004). 
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For  information  on  Spirent  Communications  and  their  products,  contact  Jeff 
Blanchard  at  408-752-7159  (office)  or  408-464-8948  (cell).  His  e-mail  address  is 
ieff.blanchard@spirentcom.com. 

T.  ZYFER  (GPS) 

Originally  named  Odetics  Telecom,  Zyfer  was  established  in  the  mid-'80s,  and 
incorporated  as  Zyfer  Inc.  in  1999.  FEI-Zyfer's  parent  company.  Frequency  Electronics 
Inc.  (FEI),  was  founded  in  1961  and  quickly  gained  world  prominence  in  the  Precision 
Quartz  Crystal  Oscillator  Technology.  FEI-Zyfer  designs  and  manufactures  GPS-aided 
precision  time  and  frequency  generation  and  synchronization  products  for  commercial 
and  government  users.  It  is  based  out  of  Anaheim,  CA.112 

During  this  thesis  research  at  Raytheon,  the  Nanosync  II  was  used  to  provide 
synchronization  to  both  of  Spirent’s  chassis.  This  would  allow  for  the  VoIP  QoS 
software  to  show  accurate  latency  data.  Unfortunately,  one  of  the  GPS  receivers  was 
positioned  too  close  to  a  building,  so  it  could  not  pick  up  enough  satellites  to  provide 
proper  signal.  This  location  could  not  be  moved.  Thus,  both  chassis  could  not  sync  up 
and  the  latency  data  ended  up  being  skewed.  The  Nanosync  II  was  very  lightweight  and 
easy  to  use.  It  does  take  a  special  cable  between  the  receiver  and  the  antenna  cable  to  be 
utilized. 

For  information  on  FEI-Zyfer  and  their  products,  contact  Lee  Chenoweth  at  949- 
713-9801  (office)  or  949-433-2800  (cell).  His  e-mail  address  is 
lee@timingtechnolo  gies .  com. 

U.  SOLARWINDS 

SolarWinds.Net,  Inc.  was  founded  in  1995  and  is  headquartered  in  Tulsa, 
Oklahoma.  SolarWinds  develops  and  markets  an  array  of  network  management,  network 
monitoring,  and  network  discovery  tools.  SolarWinds  is  organized  in  three  divisions; 
Network  Toolset  Division,  the  Orion  Division,  and  the  Broadband  Division.  The  division 
that  enhances  and  releases  new  network  tools  is  the  Network  Toolset  Division.  The 

112  http://www.zvfer.cotn/aboutus.html  (April  2004). 
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division  that  works  on  server  based  solutions  providing  a  complete  web  view  of  the 
network  is  the  Orion  Division.  Finally,  the  division  that  develops  solutions  for  high¬ 
speed  data  networks  is  the  Broadband  Division.  ii3  According  to  SolarWinds,  their 
mission  is  “to  provide  Network  Engineers  and  Consultants  with  a  single  comprehensive 
tool-set  to  reactively  and  proactively  analyze,  monitor  and  isolate  networking  issues.”ii4 

As  mentioned  in  the  thesis,  SolarWinds  was  used  to  monitor  the  throughput  in  the 
network.  Through  the  use  of  Simple  Network  Management  Protocol  (SNMP)  with  IP 
Network  Browser  and  Internet  Control  Message  Protocol  (ICMP)  the  students  were  able 
to  monitor  the  bandwidth  utilization  of  a  remote  component  on  the  network,  the  load  on  a 
Cisco  router,  or  identify  what  devices  were  on  a  subnet.  Additional  detailed  information 
it  returned  included  details  of  each  interface,  port  speed,  IP  Addresses,  routers,  ARP 
tables,  and  much  more. 

During  the  testing  periods,  the  students  ensured  the  devices  on  the  network  were 
SNMP  enabled  prior  to  conducting  any  tests.  SolarWinds  measured  CPU  load  and  the 
Cisco  routers  load.  The  gauge  used  SNMP  to  communicate  with  the  device  and 
displayed  the  results  on  the  computer  screen  (Figure  80). 


Figure  8 1 .  SOLARWINDS  CPU  GAUGE 


The  maximum  throughput  number  was  recorded  onto  a  spreadsheet  as  the 
maximum  throughput  between  two  sites. 

113  http://www.solarwinds.net  (May  2004) 

114  http://www.solarwinds.net/companv  (May  2004) 
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For  more  information,  contact  Sales  Department  (918)  307-8100  or 

www.solarwinds.net. 


V.  IPERF 

Iperf  was  a  tool  used  to  measure  Transfer  Control  Protocol  (TCP,  a  protocol 
developed  for  the  Internet  to  get  data  from  one  network  device  to  another)  bandwidth, 
allowing  the  tuning  of  various  parameters  and  User  Datagram  Protocol  (UDP) 
characteristics.  Iperf  reports  bandwidth,  delay  jitter,  and  datagram  loss.  The  program 
can  be  downloaded  for  free  from  the  Internet.  The  authors  used  Iperf  version  1. 1. 1, 
which  was  released  in  February  2000  for  all  the  testing  found  in  this  thesis.  There  were  a 
couple  of  ways  to  execute  the  program.  One  way  was  to  run  the  batch  file  on  the  sending 
side  while  simultaneously  running  the  batch  file  on  the  receiver’s  side.  The  second 
option  was  to  go  into  the  DOS  prompt  and  type  in  the  following  commands  once  the  user 
was  in  the  Iperf  folder,  the  sender  would  type  “IPERF  -c”  (IP  address  packets  are  going 
to)  “-W  8K  5  20”  and  the  receiver  would  type  “IPERF  -s  -w  64K”.  The  meanings  of  the 
letters  above  are  as  follows:  -c  means  to  run  Iperf  in  client  mode;  -w  determines  the  TCP 
window  size  (sets  the  socket  buffer  sizes  to  the  specified  value,  in  the  example  above  the 
window  size  is  8K.  For  TCP,  this  sets  the  TCP  window  size.);  5  is  the  transmit  time  of 
bytes;  20  is  the  time  interval  of  transmission;  -s  means  to  run  Iperf  in  client  mode, 
connecting  to  an  Iperf  address  that  is  running  the  host;  -w  is  the  window  size  for  the 
receiving  side,  in  this  case,  the  size  of  the  window  is  64K. 

Currently,  there  is  an  Iperf  version  1.7.0  that  can  be  downloaded  from  the 
Internet.  If  interested  in  more  information  on  Iperf,  go  to  http://dast.nlanr.net/. 


W.  VOIP 

Voice  over  Intenet  Protocol  (VoIP)  defines  a  way  to  carry  voice  calls  over  an  IP 
network  including  the  digitization  and  packetization  of  the  voice  streams.  IP  Telephony 
utilizes  the  VoIP  standards  to  create  a  telephony  system  where  higher-level  features  such 
as  advanced  call  routing,  voice  mail,  contact  centers,  etc.,  can  be  utilized.  115 

115  http://www.cisco.cotn/en/US/tech/tk652/tk701/tech  protocol  family  home.html  (April  2004). 
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Cisco  7960G  IP  telephones  were  used  to  provide  voice  service  to  the  Local  Area 
Networks  (LAN).  The  phones  took  a  simple  CAT- 5  cable  conneetion,  and  the  other  end 
was  conneeted  to  the  LAN  switeh.  The  Call  Manager  server  was  always  loeated  with  the 
Mobile  Researeh  Facility  (MRF).  The  phones  throughout  the  Wide  Area  Network  would 
first  talk  to  the  server  before  making  a  eall  to  another  phone  within  the  network.  The 
server  was  eonnected  to  the  MRF  switch  via  CAT-5  cable.  Each  phone  and  server  was 
assigned  its  own  unique  IP  address. 

From  the  testing,  whenever  SolarWinds  measured  a  signifieant  packet  loss  of 
greater  than  10%  in  the  links  established  between  LANs,  VoIP  calls  would  drop.  The 
exception  to  this  was  using  OFDM.  Sinee  this  technology  splits  its  bandwidth  into 
multiple  channels,  as  long  as  one  ehannel  is  getting  aeross  it  will  keep  the  call  up.  For 
example,  when  SolarWinds  showed  the  link  was  down,  greater  than  50%  packet  loss,  the 
VoIP  eall  was  still  active.  Finally,  the  network  routers  were  all  set  to  have  voice  as  the 
number  one  priority. 

For  further  information  on  the  VoIP  testing  data,  reference  LT  Manny  Cordero’s 
thesis  research.  This  can  be  found  through  the  NPS  library  at 
http://librarv.nps.navv.mil/home. 

X.  MLB  (UAV) 

Sinee  1988,  MLB  has  defined  the  state  of  the  art  in  small  aerial  platforms  that 
inelude  the  tiny  Troehoid  micro  UAV,  the  large  Voleano,  and  the  workhorse  Bat.  MLB 
is  a  small  company  with  their  business  office  located  in  Mountain  View,  CA.  They  were 
contracted  to  support  the  Mareh  testing  with  their  Voleano  UAV.  The  Volcano  aircraft  is 
designed  to  earry  a  15  lb  payload  and  up  to  an  altitude  of  12000  ft.ii6 

During  the  March  testing,  the  Volcano  was  utilized  as  a  communieations  relay.  A 
small  wooden  platform  was  strapped  to  the  bottom  of  the  plane  with  an  omni-direetional 
antenna,  access  point,  DC  to  AC  power  eonverter,  and  one  lithium  battery  used  as  the 
power  source.  The  aireraft  flew  for  about  3  hours  a  day  for  a  three-day  period.  It  was 
flying  at  altitudes  from  400  to  1,000  feet.  There  was  an  onboard  eamera  that  could  be 

116  http://www.spvplanes.cotn/companv.html  (April  2004). 
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viewed  from  the  base  station  where  the  aireraft  was  being  eontrolled.  Thus,  the  Volcano 
could  double  in  its  mission  by  doing  aerial  reconnaissance  and  communications  relay 
simultaneously. 

The  aircraft  was  launched  from  the  airfield  runway,  which  it  required  about  500 
feet  of,  with  a  handheld  remote-control  device.  Once  it  was  airborne,  the  computer 
program  designed  for  the  Volcano  automatically  controlled  the  UAV  in  accordance  with 
the  inputted  track  data.  This  program  was  able  to  save  the  track  information  from  the 
entire  flight,  so  one  could  tell  where  the  aircraft  had  flown  during  its  mission. 

Communications  on  the  ground  to  the  UAV  were  very  challenging  mostly  due  to 
the  antenna  setup.  Omni-directional  antennas  of  5  dBi  gain  with  1-Watt  amplifiers  were 
used  on  the  ground  and  in  the  air.  It  was  believed  that  the  reason  communication  proved 
so  difficult  was  the  antenna  on  the  UAV  was  pointing  down  from  the  bottom  of  the 
aircraft.  Thus,  its  radiation  pattern  was  mostly  blocked.  Ideally,  the  antenna  should  have 
been  mounted  pointing  up  in  an  open  area  on  the  aircraft.  Another  solution  is  to  put 
better  gain  antennas  and/or  higher-powered  amplifiers  both  on  the  ground  and  in  the  air. 

For  information  on  MLB  Company  and  their  UAVs,  contact  Stephen  Morris  at 
650-966-1022  (office)  or  650-757-5613  (cell).  His  e-mail  address  is 
smorris@spvplanes.com. 


Y.  TETHERED  BALLOON 

The  tethered  balloon  is  approximately  12  feet  in  diameter  when  filled  completely 
with  helium.  Several  tanks  of  helium  are  needed  for  operation  of  the  balloon.  It  takes 
roughly  an  hour  to  fill  the  balloon  completely  with  helium.  Since  the  balloon  was  used 
on  multiple  days,  it  was  kept  filled  overnight  and  tied  down.  This  alleviated  the  need  to 
constantly  refill  it.  If  there  are  winds  over  15  mph,  the  balloon  should  be  deflated 
overnight  to  eliminate  any  possible  damage.  While  airborne,  the  balloon  does  not 
perform  well  in  high  winds  either.  Any  wind  over  20  mph,  the  balloon  should  not  be 
flown  to  alleviate  any  possible  damage.  In  addition,  due  to  the  constant  movement  of  the 
balloon  in  high  winds,  any  connectivity  trying  to  be  established  is  very  unreliable. 
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The  balloon  can  carry  a  payload  of  up  to  50  pounds.  As  seen  in  Figure  4,  the 
payload  is  located  underneath  the  balloon.  For  the  March  testing,  the  payload  contained 
an  omni-directional  antenna,  access  point,  1-Watt  Amplifier,  DC  to  AC  power 
converters,  and  two  Lithium  batteries  used  as  the  power  source.  A  research  associate  at 
NFS,  Kevin  Jones,  built  this  payload. 

To  let  out  or  bring  in  the  balloon,  an  attached  motor  controlled  a  large  reel  of 
string.  The  balloon  could  reach  an  altitude  of  approximately  3,000  feet.  To  fly  the 
balloon,  a  large  open  area  was  needed  because  high  winds  could  cause  the  balloon  to  be 
pushed  horizontal  rather  than  vertical.  Figure  81  displays  the  balloon  while  airborne. 


ft 


Figure  82.  TETHERED  BALLOON  WITH  PAYLOAD  UNDERNEATH 

Z.  FIELD  TEST  TEMPLATE 

The  following  information  is  a  template  that  was  used  in  the  writing  of  the  field 

tests. 

TEST  PLAN  and  REPORT  FORMATS 


GENERAL:  Ideally,  an  experiment  is  reported  on  in  two  documents,  an 
experimental  plan  that  lays  the  foundation,  and  an  experimental  report  that  tells  what 
actually  took  place  and  what  the  results  were.  For  this  thesis  work  the  authors  did  not 
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produce  elaborate  experimental  plans,  so  they  moved  some  of  the  information  into  the 
report.  The  following  outline  is  suggested.  Parenthetical  notes  identify  further 
explanation  of  information  that  is  contained  in  the  section. 

1.  Introduction 

A.  Introduce  the  team  (who) 

B.  Purpose 

C.  The  real  world  problem  the  experiment  will  help  solve  (what) 

D.  The  specific  questions  the  experiment  seeks  to  answer 

E.  The  Methodology  (approach  -  how) 

F.  Anticipated  Results 

G.  Scope  of  Experiment  (why) 

2.  Experimental  Design 

A.  Setup 

B.  Physical  (location  and  time  frame  of  experiment  -when,  and  where) 

C.  Test  subjects  (technologies  tested) 

D.  Schedule  of  Trials  (planned  schedule) 

E.  Assumptions 

F.  Statistical  Design  of  Experiment  (network  diagram) 

G.  Instrumentation  (equipment  used  for  collecting  data) 

H.  Testing  &  Pilot  Trials  (baseline  results) 

3.  Data  Description 

A.  Example  of  raw  data 

B.  Data  problems 

C.  Data  table 
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4.  Analysis  (both:  findings  and  analysis) 

A.  Findings 

B.  Analysis  (summary  of  experiment) 

5.  Conclusions 

A.  Experiment  Summary 

B.  Real  world  results  of  experiment 

6.  Recommendations 

A.  Changes  to  the  Experiment 

B.  Continuation  of  the  Experiment 
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LIST  OF  ACRONYMS  AND  ABBREVIATIONS 


ACE 

Aviation  Combat  Element 

ATC 

Air  Traffic  Control 

ATM 

Asynchronous  Transfer  Mode 

BIOS 

Beyond  Line  of  Sight 

CAC2S 

Common  Aviation  Comand  and  Control  System 

CE 

Command  Element 

COC 

Combat  Operations  Center 

Condor 

Command  and  Control  On  the  Move  Network,  Digital  Over  the  Horizon  Relay 

cs 

Communications  Subsystem 

CSSE 

Combat  Service  Support  Element 

DASC 

Direct  Air  Support  Center 

DOD 

Department  of  Defense 

DSU 

Digital  Switch  Unit 

EIGRP 

Enhanced  Interior  Gateway  Routing  Protocol 

EPLRS 

Enhanced  Position  Locating  and  Reporting  System 

FSO 

Free  Space  Optics 

GCE 

Ground  Combat  Element 

GDDS 

General  Dynamics  Decision  Systems 

GET 

Generator,  Environmental  Control  Unit,  and  Tent 

GUI 

Graphical  User  Interface 

HP 

High  Frequency 

HMMWV 

High  Mobility  Multi-Purpose  Wheeled  Vehicle 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers 

IMUX 

Iridium  Inverse  Multiplexer 

INE 

In-Line  Network  Encryptor 

IP 

Internet  Protocol 

JTRS 

Joint  Tactical  Radio  System 

LAAD 

Low  Altitude  Air  Defense 

LAN 

Local  Area  Network 

LOS 

Line  of  Sight 

MAC 

Media  Access  Control 

MACCS 

Marine  Aviation  Command  and  Control  System 

MAGTF 

Marine  Aviation-Ground  Task  Force 

MAR 

Mobile  Access  Router 

MCSC 

Marine  Corps  Systems  Command 

MCTSSA 

Marine  Corps  Tactical  Systems  Support  Activity 

MEF 

Marine  Expeditionary  Force 

MRC 

Mobile  Radio  Component 

MRF 

Mobile  Research  Facility 

MSC 

Major  Subordinate  Command 

NLOS 

Non  Line  of  Sight 

NOC 

Network  Operations  Center 

NPS 

Naval  Postgraduate  School 

ODU 

Outdoor  Mounted  Unit 
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OFDM 

Orthogonal  Frequency  Division  Multiplexing 

OIF 

Operation  Iraqi  Freedom 

OTH 

Over  The  Horizon 

PDS 

Processing  and  Disply  Subsystem 

POP 

Point  of  Presence 

PRC 

Portable  Radio  Component 

RF 

Radio  Frequency 

RFM 

Radio  Frequency  Module 

SCOP 

Skinny  Client  Control  Protocol 

SDS 

Sensor  Data  Subsystem 

SIP 

Session  Initiated  Protocol 

SMART-T 

Secure,  Mobile,  Anit-Jam,  Reliable  Tactical  Terminal 

SSID 

Service  Set  Identifier 

TACO 

Tactical  Air  Command  Center 

TAOC 

Tactical  Air  Operations  Center 

TCP 

Transport  Control  Protocol 

TDN 

Tactical  Data  Network 

TRC 

Tactical  Radio  Component 

UAV 

Unmanned  Aerial  Vehicle 

UHF 

Ultra  High  Frequency 

UOC 

Unit  Operations  Center 

USMC 

United  States  Marine  Corps 

USN 

United  States  Navy 

VHF 

Very  High  Frequency 

VoIP 

Voice  over  Internet  Protocol 

WAN 

Wide  Area  Network 

WAP 

Wireless  Access  Point 
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